Herramienta de Generación de Código Framework ATLAS

Transcripción

1 Herramienta de Generación de Código Framework ATLAS Versión 1.6 Arquitectura de Software

2 Hoja de Control Título Documento de Referencia Responsable Manual de Usuario de la Herramienta de Generación de Código de ATLAS NORMATIVA ATLAS ICM Versión 1.6 Fecha Versión 30/04/ Revisado/Validado por: Fecha Revisión/Validación 2 Aprobado por: Fecha Aprobación Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento Área de Aplicaciones Especiales y Arquitectura de Software 23/02/2012 Nueva versión de la herramienta que incluye generación de pantallas. Listado de ficheros modificados Área de Aplicaciones Especiales y y/o creados por la herramienta 12/06/2012 Arquitectura de Software Documentada incrementalidad parcial. Documentado alcance y funcionalidades futuras Modificada Introducción e Área de Aplicaciones Especiales y incluido apartado Descripción de 26/10/2012 Arquitectura de Software código que se genera La herramienta pregunta por las Área de Aplicaciones Especiales y capas de la aplicación que se 26/02/2013 Arquitectura de Software desea generar - Añadido un aviso de configurar la BBDD de la aplicación además de la del generador - Nuevos filtros para la pantalla de búsqueda. - Añadido soporte para vistas y campos LOB. Arquitectura de Software 5/06/ Modificada la ingeniería inversa en las tablas sin PK y creado fichero de propiedades de ingeniería inversa. - Eliminado apartado 5 de alcance de la herramienta. - Indica que se crea al fichero hibernate.reveng.log Arquitectura de Software 27/11/ Añadida la opción de mostrar el formulario detalle en un pop-up Página 2 de 37

3 1.6 Framework Atlas Versión Causa del Cambio Responsable del Cambio Fecha del Cambio - Inclusión de las instrucciones para comprobar con CheckStyle y PMD el código una vez generado, formateado y limpiado. Arquitectura de Software 29/04/2014 Página 3 de 37

4 Índice 1 INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCION DEL CODIGO QUE SE GENERA ACCESO A DATOS SERVICIOS DE NEGOCIO PRESENTACION PRUEBAS USO DE LA HERRAMIENTA CONFIGURACIÓN DE LA CONSOLA DE HIBERNATE CONFIGURACIÓN DEL PAQUETE JAVA CONFIGURACIÓN DE LA CONEXIÓN A BASE DE DATOS SELECCIÓN DE LAS TABLAS EJECUCIÓN COMPROBACIÓN DE CÓDIGO GENERADO COMPROBACION DE FORMATO DEL CÓDIGO GENERADO EJECUCIÓN DE LA APLICACIÓN USO INCREMENTAL DE LA HERRAMIENTA Página 4 de 37

5 Contenido 1 INTRODUCCIÓN A partir de la versión del framework de desarrollo de aplicaciones ATLAS, se incluye una herramienta de generación automática de código. Esta herramienta permite, a partir de un modelo de datos, generar código para gestionar las operaciones básicas (alta, baja, modificación y consulta) de ese modelo de datos de acuerdo a la normativa del framework Atlas en las distintas capas de la aplicación. La herramienta nos permite seleccionar las tablas de las que queremos generar el código, y a partir de ellas realiza una ingeniería inversa del modelo de datos y genera el código en la aplicación. También detecta las vistas si su nombre cumple la normativa de base de datos. Para el desarrollo de la herramienta se ha tomado como punto de partida el plugin JBoss Hibernate Tools, y se ha personalizado su configuración para adaptarlo a las necesidades propias de ATLAS. Atención El código fuente generado es un punto de partida para el desarrollo. Lo generado se debe evolucionar para adaptarlo a las necesidades y requisitos específicos del proyecto. En este documento se describe el código generado, cómo configurar la herramienta y cómo utilizarla. 1.1 AUDIENCIA OBJETIVO Este documento está orientado a toda aquella persona que desee desarrollar una aplicación con el framework ATLAS y para ello requiera interaccionar con un modelo de datos. 1.2 CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: Lenguaje Java Spring JSF Hibernate Framework de desarrollo de aplicaciones ATLAS Página 5 de 37

6 2 DESCRIPCION DEL CODIGO QUE SE GENERA En este apartado se muestra para cada una de las capas del framework Atlas los diagramas de clases del código que se genera y la descripción de cada uno de los elementos creados y/o modificados para cada una de las capas de la aplicación. Se ha tomado como ejemplo una entidad de base de datos llamada Expediente. 2.1 ACCESO A DATOS En los desarrollos con framework Atlas nos vamos a encontrar con que una gran parte del desarrollo implica la capa de acceso a base de datos. En el framework Atlas se ha definido que dicho acceso sea con Hibernate y con implementaciones de clases de dominio y dao. La herramienta va a generar las clases que la normativa del framework Atlas determina (Clases de dominio y DAOS) para las operaciones básicas de consulta, alta, baja y modificación. Además se a van a realizar las correspondientes actualizaciones en los ficheros de configuración de Spring para que estas clases puedan ser usadas desde los servicios de negocio. A continuación se indican los elementos que se van a generar o modificar para cada una de las entidades/tablas de las cuales se solicita la generación de código: Fichero src/main/java/xxxx/domain/yyyy.java src/main/java/xxxx/dao/basedao.java src/main/java/xxxx/dao/basedaoimpl.java src/main/java/xxxx/dao/yyyydao.java src/main/java/xxxx/dao/yyyydaoimpl.java Creación / Modificación Creación, sólo si no existe Creación, sólo si no existe Creación, sólo si no existe Descripción Entidad de dominio asociada a una tabla. Está mapeada con anotaciones de Hibernate a dicha tabla y sus campos. Ejemplo: Expediente.java Interfaz e implementación de base para todos los DAOS. Se incluyen las operaciones básicas de alta, baja, modificación y consulta de forma genérica para cualquier dao. Todos los DAOs deberán heredar de ellas para así heredar estas operaciones básicas. Si en el desarrollo de la aplicación se identifica una necesidad común para todos los DAOS se ha de incluir en estas clases. Interfaz e implementación del DAO que permite gestionar las distintas operaciones de base de datos para la entidad. Heredan de BaseDAO y BaseDAOImpl respectivamente. En la generación estas clases se quedan vacías. Las nuevas operaciones de acceso a base de datos relacionadas con las entidad se han de implementar en estas clases. Ejemplo: ExpedienteDAO.java y ExpedienteDAIMpl.java Página 6 de 37

7 src/main/resources/conf/applicationcontextdatabase.xml src/main/resources/conf/applicationcontextdao.xml Modificación Modificación Se incluye el paquete de las clases de dominio generadas en la entrada packagestoscan para que las reconozca Hibernate. Se incluye la definición de un bean para el DAO generado en el fichero de contexto de Spring para que pueda ser usado desde los servicios de negocio. La nomenclatura del bean es yyyydao donde yyyy corresponde con el nombre la entidad. Ejemplo: expedientedao Clases generadas para la capa de acceso a datos class Acceso a Datos «interface» dao::basedao + findall() : List<T> + countall() : Long + findalldistinct() : List<T> + countalldistinct() : Long + find(pk) : T + find(int, int, AtlasOrder[], AtlasQuery) : List<T> + count(atlasquery) : int + exists(pk) : boolean + insert(t) : T + insertorupdate(t) : void + update(t) : void + delete(pk) : void + delete(t) : void + findbynamedquery(string, Map<String, Object>) : List<T> dao::basedaoimpl - logger: Log = LogFactory.getL... {readonly} - persistentclass: Class<T> T PK:extends Serializable HibernateDaoSupport + BaseDAOImpl(Class<T>) + BaseDAOImpl(Class<T>, SessionFactory) + findall() : List<T> + countall() : Long + findalldistinct() : List<T> + countalldistinct() : Long + find(pk) : T + find(int, int, AtlasOrder[], AtlasQuery) : List<T> + count(atlasquery) : int - findinternal(atlasorder[], AtlasQuery, boolean) : Criteria + exists(pk) : boolean + insert(t) : T + insertorupdate(t) : void + update(t) : void + delete(pk) : void + delete(t) : void + findbynamedquery(string, Map<String, Object>) : List<T> # getlog() : Log «interface» dao:: ExpedienteDAO dao::expedientedaoimpl + ExpedienteDAOImpl() expedientedao : ExpedienteDAOImpl Bean de Spring para utilizar desde los servicios de negocio. domain::expediente java.io.serializable - serialversionuid: long = 1L {readonly} - idexpediente: Integer - oficina: Oficina - cdexpediente: String - dsexpediente: String - itestado: String - fcalta: Date - fcmodif: Date - cldsextendida: Clob - nmcduadmin: Integer - expeinteresados: Set<ExpeInteresado> = new HashSet<Exp... - expearchivos: Set<ExpeArchivo> = new HashSet<Exp... + Expediente() + Expediente(Integer) + Expediente(Integer, Oficina, String, String, String, Date, Date, Clob, Integer, Set<ExpeInteresado>, Set<ExpeArchivo>) + getidexpediente() : Integer + setidexpedi ente(integer) : voi d + getpkasstring() : String + getpkfromstring(string) : Integer + getoficina() : Oficina + setoficina(oficina) : void + getcdexpediente() : String + setcdexpediente(string) : void + gettextolistavalores() : String + getdsexpediente() : String + setdsexpediente(string) : void + getitestado() : String + setitestado(string) : void + getfcalta() : Date + setfcalta(date) : void + getfcmodif() : Date + setfcmodif(date) : void + getcldsextendida() : Clob + setcldsextendida(clob) : void + getnmcduadmin() : Integer + setnmcduadmin(integer) : void + getexpeinteresados() : Set<ExpeInteresado> + setexpeinteresados(set<expeinteresado>) : void + getexpearchivos() : Set<ExpeArchivo> + setexpearchivos(set<expearchivo>) : void + tostring() : String + equals(object) : boolean + hashcode() : int 2.2 SERVICIOS DE NEGOCIO En la capa de servicios de negocio la herramienta se van a generar las clases que la normativa del framework Atlas determina (Fachada y Servicios) para las operaciones básicas de consulta, alta, baja y modificación invocando para su ejecución a los DAOs de la capa de acceso a datos. Además va a realizar las correspondientes configuraciones para incluir objetos de estos servicios en el contexto de Spring.. Página 7 de 37

8 A continuación se indican los elementos que se van a generar o modificar para cada una de las entidades/tablas de las cuales se solicita la generación de código: Fichero src/main/java/xxxx/services/baseservice.java src/main/java/xxxx/services/baseserviceimpl.java src/main/java/xxxx/services/yyyyservice.java src/main/java/xxxx/services/yyyyserviceimpl.java src/main/java/xxxx/services/facade/xxxxfacade.java src/main/java/xxxx/services/facade/xxxxfacadeimpl.java Creación / Modificación Creación o modificación si ya existe. Creación, sólo si no existe Creación o modificación si ya existe. Descripción Interfaz e implementación de base para todos los Servicios. Se incluyen las operaciones básicas de alta, baja, modificación y consulta de forma genérica para cualquier servicio. Todos los Servicios deberán heredar de ellas para así heredar estas operaciones básicas. Si en el desarrollo de la aplicación se identifica una necesidad común para todos los Servicios se ha de incluir en estas clases. Interfaz e implementación del Servicio que permite gestionar las distintas operaciones que se pueden realizar con la entidad. Heredan de BaseService y BaseServiceImpl respectivamente. En la generación estas clases se quedan vacías ya que heredan la operativa básica. Las nuevas operaciones de este servicio se han de implementar en estas clases. Ejemplo: ExpedienteService.java y ExpedienteServiceIMpl.java Clases con la fachada y la implementación para el paquete xxxx. Ejemplo PruebasFacade.java y PruebasFacadeImpl.java Página 8 de 37

9 src/main/resources/conf/applicationcontextservices.xml Modificación Se incluye la definición de un bean para el servicio generado al cual se le inyecta el bean del dao correspondiente. La nomenclatura del bean del servicio es yyyyservice donde yyyy corresponde con el nombre la entidad. Ejemplo: expedienteservice Además se crea y/o modifica el bean de la fachada para inyectar el servicio. La nomenclatura del bean de la fachada es xxxxfacade donde xxxx corresponde con el nombre del paquete donde se han generado las clases. Ejemplo: expedientefacade. A continuación se muestra un diagrama que incluye las clases generadas para la capa de servicio de negocio para una entidad de ejemplo llamada Expediente: Código generado para la capa de servicio de negocio class Serv icio «interface» services::baseservice + setdao(d) : void + getdao() : D + findall() : List<T> + countall() : Long + findalldistinct() : List<T> + countalldistinct() : Long + find(pk) : T + find(int, int, AtlasOrder[], AtlasQuery) : List<T> + count(atlasquery) : int + exists(pk) : boolean + insert(t) : T + insertorupdate(t) : void + update(t) : void + delete(pk) : void + delete(t) : void + findbynamedquery(string, Map<String, Object>) : List<T> «interface» services:: ExpedienteServ ice -expedienteservice facade::pruebasfacadeimpl - expedienteservice: ExpedienteService + setexpedi enteservi ce(expedienteservi ce) : voi d + findexpediente(int, int, AtlasOrder[], AtlasQuery) : List<Expediente> + findexpediente(integer) : Expediente + countexpediente(atlasquery) : int + insertexpediente(expediente) : void + updateexpediente(expediente) : void + insertorupdateexpediente(expediente) : void + deleteexpediente(expediente) : void + deleteexpediente(integer) : void services::baseserviceimpl - logger: Log = LogFactory.getL... {readonly} - dao: D T PK:extends Serializable D:extends BaseDAO<T, PK> + setdao(d) : void + getdao() : D + findall() : List<T> + countall() : Long + findalldistinct() : List<T> + countalldistinct() : Long + find(pk) : T + find(int, int, AtlasOrder[], AtlasQuery) : List<T> + count(atlasquery) : int + exists(pk) : boolean + insert(t) : T + insertorupdate(t) : void + update(t) : void + delete(pk) : void + delete(t) : void + findbynamedquery(string, Map<String, Object>) : List<T> expedientedao : ExpedienteDAOImpl services:: ExpedienteServiceImpl expedienteservice : ExpedienteServiceImpl expediente : Expediente «interface» facade::pruebasfacade + findexpediente(int, int, AtlasOrder[], AtlasQuery) : List<Expediente> + findexpediente(integer) : Expediente + countexpediente(atlasquery) : int + insertexpediente(expediente) : void + updateexpediente(expediente) : void + insertorupdateexpediente(expediente) : void + deleteexpediente(expediente) : void + deleteexpediente(integer) : void pruebasfacade : PruebasFacadeImpl Bean de Spring para ser usado desde l os beans de respaldo de JSF Página 9 de 37

10 2.3 PRESENTACION En la capa de presentación se generan para cada una de las entidades/tablas unas pantallas que nos permitan realizar el mantenimiento básico de dicha tabla. La generación de la parte de presentación está pensada como una solución para generar el código asociado al mantenimiento de catálogos que típicamente podemos encontrar en las aplicaciones. En el caso de las vistas no se generan las acciones de eliminar ni editar en el listado, ni el formulario de edición, y es posible especificar si se quieren tratar todas las tablas como vistas. Se generan los siguientes elementos de código: Fichero src/main/java/xxxx/jsf/yyyybean.java src/main/webapp/secure/catalogos.xhtml src/main/webapp/secure/listayyyy.xhtml src/main/webapp/secure/formularioyyyy.xhtml Creación / Modificación Creación, sólo si no existe Creación si no existe Creación si no existe Creación si no existe (no se genera en el caso de vistas o entidades de sólo lectura) Descripción Clase del bean de respaldo de JSF para la gestión de operaciones de la entidad. Incluye las operaciones que se van a hacer desde las distintas pantallas. Este bean interactua con los servicios de negocio invocando a través de la fachada. Ejemplo: ExpedienteBean Página principal de administración de catálogos. Se trata de una página inicial de ejemplo que se puede personalizar para cada aplicación. Página JSF que muestra un tabla paginada con los elementos de la entidad y filtros para cada uno de los campos que permitan realizar busquedas. Más adelante se muestra como es gráficamente esta página. Ejemplo: listaexpediente.xhtml Página JSF que muestra un formulario con los campos de la entidad. Esta misma página se utilizar para dar de alta un nuevo elemento y para editar uno ya existente. Más adelante se muestra como es gráficamente esta página. Ejemplo: formularioexpediente.xhtml. Página 10 de 37

11 src/main/resources/menu.xml src/main/webapp/web-inf/faces-managedbeans.xml src/main/webapp/web-inf/faces-navigation.xml src/main/java/xxxx/jsf/navigationresults.java Modificación Modificación Modificación Modificación (si no existen ya los cambios) Incluye una nueva opción de menú dentro de la opción Mantenimiento de Catálogos para acceder a la pantalla listayyyy. Incluye la declaración del bean de respaldo para que pueda ser usado desde las páginas JSF. Este bean se declara en ambito request. La nomenclatura es es yyyybean donde yyyy corresponde con el nombre la entidad. Ejemplo: expedientebean Incluye las reglas de navegación para las distintas pantallas. Ver gráfico facesnavigation más abajo. Resultados de navegación de las distintas páginas JSF, que se utilizan en facesnavigation.xml src/main/resources/msg/messages_es.properties Modificación Todos los textos mostrados en las pantallas se incluyen en el ficheros de mensajes. Cualquier modificación de los textos se ha de hacer en este fichero. Página 11 de 37

12 A continuación se muestra el código generado en la capa de presentación: Código generado: Presentación class Presentacion listaexpediente.xhtml formularioexpediente.xhtml expedientebean : ExpedienteBean expedientebean : ExpedienteBean Managed Bean para ser usado desde l as páginas JSF jsf::expedientebean - serialversionuid: long = 1L {readonly} - facade: PruebasFacade - orderandfilter: OrderAndFilterBean = null - entidad: Expediente = null - listavaloresoficina: ListaValores - textooficina: String - oficinafilter: String - cdexpedientefilter: String - dsexpedientefilter: String - itestadofilter: String - fcaltafilter: Date - fcmodiffilter: Date - scroller: UIDataScroller = new UIDataScroller() + ExpedienteBean() + getentidad() : Expediente + setenti dad(expedi ente) : voi d + getfacade() : PruebasFacade + setfacade(pruebasfacade) : voi d + gettimezone() : TimeZone + getorderandfilter() : OrderAndFilterBean + setorderandfi l ter(orderandfi l terbean) : voi d + obtener(int, int, Object, Object) : List<Expediente> + obtenertotal(object) : int + cargar() : String + cargar(actionevent) : void + eliminar() : String + eliminar(actionevent) : void + confirmareliminar() : String + confirmareliminar(ajaxbehaviorevent) : void + guardar() : String + nuevo() : String + volver() : String + getlistavaloresoficina() : ListaValores + setli staval oresofi ci na(li staval ores) : voi d + sett extoofi ci na(stri ng) : voi d + gettextooficina() : String + obtenerlistaoficina(int, int, Object, Object) : List<AtlasHashMap> + obtenertotaloficina(object) : int + getoficinafilter() : String + setofi ci nafil ter(stri ng) : voi d + getcdexpedientefilter() : String + setcdexpedi entefi l ter(stri ng) : voi d + getdsexpedientefilter() : String + setdsexpedi entefi l ter(stri ng) : voi d + getitestadofilter() : String + setitestadofi l ter(stri ng) : voi d + getfcaltafilter() : Date + setfcal tafi l ter(date) : voi d + getfcmodiffilter() : Date + setfcmodi ffi l ter(date) : voi d + getscroller() : UIDataScroller + setscrol l er(uidatascrol l er) : voi d + filtrar() : String + setidofi ci na(stri ng) : voi d + getrequiredmessage() : String -facade -entidad java.io.serializable domain::expediente «interface» facade::pruebasfacade + countexpediente(atlasquery) : int + insertexpediente(expediente) : void + updateexpediente(expediente) : void + findexpediente(int, int, AtlasOrder[], AtlasQuery) : List<Expediente> + findexpediente(integer) : Expediente + insertorupdateexpediente(expediente) : void + deleteexpediente(expediente) : void + deleteexpediente(integer) : void Página 12 de 37

13 A continuación se muestra un gráfico que muestra la navegación entre las páginas JSF generadas: faces-navigation A continuación se muestran ejemplos de pantallas generadas para el mantenimiento de la entidad Expediente. Ejemplo de página xhtml generada Listado: listaexpediente.xhtml Desde esta pantalla nos permite realizar las siguientes operaciones: Búsqueda basada en filtros Borrar los filtros para realizar una nueva búsqueda Página 13 de 37

14 Nuevo elemento: Accede a la pantalla de alta Eliminación: Borra un registro (no aparece en vistas y entidades de sólo lectura) Edición: Accede a la pantalla de edición (no aparece en vistas y entidades de sólo lectura) Características de esta pantalla: Filtros: o Para cada campo de la tabla de tipo String se genera un <inputtext> para buscar por ese campo. o En el caso de que un campo sea una foreign key de una tabla se genera un <inputtext> para buscar en el primer campo de tipo texto de la tabla foránea. o En el caso de un campo fecha se genera un campo que nos permite filtrar por una fecha, rango de fechas, antes/después de una fecha o registro nulo. o En el caso de campos numéricos se genera un campo que nos permite filtrar por criterios de igualdad, mayor/menor, intervalo o registro nulo. Tabla de resultados: o Ordenación por columnas o Paginación por ajax o Exportación a Excel o PDF (Pudiendo seleccionar columnas y modificar el orden en el documento de salida). o Para los campos de tipo LOB se genera un icono de descarga. Ejemplo de página xhtml generada Página de alta y edición: formularioexpediente.xhtml Página 14 de 37

15 Características de esta pantalla: Campos que son foreign key de otra tabla se genera un <inputtext> asociado a una lista de valores Campos de tipo Date: se genera un campo de tipo Calendario Campos de tipo String: se genera un <inputtext> limitado al tamaño máximo de la columna en base de datos Campos numéricos: se genera un <inputtext> con validadores asociados para que el contenido no exceda el tamaño máximo permitido en base de datos Campos de tipo BLOB: se genera un <inputtext> de sólo lectura que muestra el tamaño en bytes del contenido e iconos de acción para sustituir el contenido (mediante un componente fileupload), descargarlo o eliminarlo (estos dos últimos sólo se muestran si hay contenido) File upload para añadir contenido a un campo BLOB Campos de tipo CLOB: se genera un <inputtext> de sólo lectura que muestra los primeros caracteres del campo. Pinchando sobre el inputtext se abre un panel modal para editar el contenido. Además, se generan los mismos iconos de acción que en el caso de los campos de tipo BLOB (subida mediante file upload, descarga y eliminación de contenido) Panel modal de edición de campo CLOB Página 15 de 37

16 Resto de campos se genera un <inputtext> Cada campo lleva asociado un enlace a una ayuda de contexto Se marcan en amarillo los campos obligatorios y se muestra un mensaje si no se rellenan El siguiente diagrama muestra como interactúan entre sí los distintos elementos de código generados. Se ha realizado para la operación de guardar pero el resto de operaciones siguen el mismo patrón: Diagrama de secuencia para guardar un expediente sd Class Model expedientebean :ExpedienteBean pruebasfacade :PruebasFacadeImpl expedienteservice :ExpedienteServiceImpl expedientedao :ExpedienteDAOImpl formularioexpediente Hibernate guardar() :String insertorupdateexpediente(expediente) insertorupdate(t) insertorupdate(t) 2.4 PRUEBAS Además se generan pruebas unitarias para la clase del Servicio, salvo en el caso de vista o tablas de sólo lectura. Fichero src/test/java/xxxx/services/yyyyservicetest.java src/main/resources/conf/applicationcontextservices.xml Creación / Modificación Creación, sólo si no existe Modificación Descripción Clase JUnit para testear la clase del servicio de negocio generada. Modificación del fichero para declarar los Beans de Spring correspondientes a fachada y/o servicios Clase generada para Test JUnit Página 16 de 37

17 class Pruebas AbstractTransactionalJUnit4SpringContextTests services::expedienteservicetest - log: Logger = Logger.getLogge... - facade: PruebasFacade - sessi onfactory: Sessi onfactory + setfacade(pruebasfacade) : voi d + setsessi onfactory(sessi onfactory) : voi d + beforetransaction() : void + aftertransaction() : void + setup() : voi d + teardown() : void + testfind1expediente() : void + testfind2expediente() : void + testcountexpediente() : void + testupdateexpediente() : void + testinsertorupdateexpediente() : void + testdelete1expediente() : void + testdelete2expediente() : void Página 17 de 37

18 3 USO DE LA HERRAMIENTA Este documento toma como punto de partida un Arquetipo Web recién generado, y asume que se dispone del entorno Eclipse correctamente configurado y con el plugin JBoss Hibernate Tools instalado. Si no se dispone del arquetipo o el entorno, puede descargarse el DVD con el entorno de desarrollo ATLAS de la web de ArquitecturaSw ( ). En los ejemplos mostrados en este documento se ha utilizado un arquetipo web generado con los siguientes parámetros: Para configurar el entorno de desarrollo para utilizar la herramienta, y posteriormente utilizarla es necesario realizar los pasos descritos en los siguientes apartados. Página 18 de 37

19 3.1 CONFIGURACIÓN DE LA CONSOLA DE HIBERNATE Antes de poder utilizar la ingeniería inversa, es necesario crear una Consola de Hibernate. Para ello, pulsamos con el botón derecho sobre la carpeta generador, seleccionamos New -> Other -> Hibernate Console Configuration : Pulsamos sobre Next y aparece la pantalla para crear una nueva consola. Página 19 de 37

20 En este pantalla, pulsamos sobre Finish y la consola ya estará creada. 3.2 CONFIGURACIÓN DEL PAQUETE JAVA Las clases que generará la herramienta estarán dentro de un paquete que puede ser configurado a través de la variable generador.paquete del fichero web/src/main/resources/environment.properties. Se deberá modificar el valor de esta variable para configurar el paquete en el que deseamos generar las clases Java: Página 20 de 37

21 3.3 CONFIGURACIÓN DE LA CONEXIÓN A BASE DE DATOS Para que la herramienta pueda conectarse a la base de datos, debemos modificar el fichero de configuración del arquetipo situado en web/generador/hibernate.cfg.xml, y modificar las siguientes propiedades: hibernate.connection.url: Cadena de conexión JDBC. - Ej: jdbc:oracle:thin:@icm21:1521:denivel2 hibernate.connection.username: Usuario de conexión a la base de datos. - Ej: DBA_EJPL hibernate.connection.password: Contraseña de conexión. hibernate.default_schema: Schema de conexión (igual que el usuario). - Ej: DBA_EJPL ATENCIÓN! Además de configurar la Base de Datos para el generador de código, no hay que olvidar configurar la Base de Datos de la aplicación como habitualmente. Es decir, modificar en el fichero enviroment.properties las variables jdbc.username=dba_ejpl jdb.password=sis Página 21 de 37

22 3.4 SELECCIÓN DE LAS TABLAS Antes de ejecutar la herramienta tenemos que seleccionar las tablas para las que queremos realizar la generación. Para ello, debemos abrir el fichero generador/hibernate.reveng.xml, y seleccionar la pestaña Table Filters : Aquí, pulsamos sobre el botón Refresh, y aparecerá un desplegable en el que debemos seleccionar consola de hibernate que ya habíamos creado: En ese momento es posible que aparezca el siguiente mensaje: Página 22 de 37

23 Pulsamos sobre Yes, y ya podemos desplegar en la zona Database Schema todas las tablas del esquema. Debemos seleccionar las tablas que queramos, y pulsar sobre Include, para pasarlas a la zona de la izquierda y que así sean utilizadas para la generación de código. Cuando hayamos terminado de seleccionar las tablas, pulsaremos sobre Save para guardar el fichero: 3.5 EJECUCIÓN Una vez que ya hemos terminado de configurar la herramienta, podemos proceder a su ejecución para generar el código. La ejecución de la herramienta se realiza mediante Maven, para ello pulsamos con el botón derecho sobre el proyecto XXXX_web, y seleccionamos Run As -> Maven build : Página 23 de 37

24 En la pantalla que aparece, deberemos rellenar los siguientes valores: - Goal: generate-resources - Profiles: generador Posteriormente pulsamos sobre el botón Run para ejecutar Maven con esos valores: Página 24 de 37

25 Comenzará entonces la ejecución de la herramienta, que mostrará todo el log por la consola. Framework Atlas Nota 1 Durante la ejecución, la herramienta hará preguntas para afinar algunos detalles del modelo, estas preguntas sólo se harán la primera vez, y las respuestas se guardarán en el fichero de propiedades hibernate.reveng.properties, ubicado en el directorio generador del módulo web, este fichero puede editarse para modificar o eliminar propiedades, en este último caso en la siguiente ejecución la herramienta volvería a hacer las preguntas. Si se ha seleccionado alguna tabla que no contenga definida una PRIMARY KEY, la herramienta de generación de código preguntará si se desea usar la lista de columna no nulas como clave primaria, mostrando en pantalla la lista de estas columnas que pueden identificar unívocamente los elementos de esa tabla: La respuesta debe ser S o N (mayúscula o minúscula). Si la respuesta es N se solicitará la lista de columnas para la clave primaria. Si la tabla no tuviera columnas no nulas no se hace la pregunta anterior, pasando directamente a solicitar los nombres de las columnas para la clave primaria. Debemos introducirlos EN MAYÚSCULA y separados por coma (si pulsamos Enter sin introducir ningún nombre de columna, utilizará todas las columnas de la tabla como clave única): Si alguna de las tablas tiene campos de tipo BLOB, la herramienta de generación de código preguntará si se desea especificar una extensión para el contenido de ese campo: Página 25 de 37

26 Si se especifica una extensión, se utilizará para añadirla al nombre del fichero de descarga en las pantallas de consulta y mantenimiento, asociando además un mime type adecuado. En caso de no especificarla el nombre del fichero de descarga no llevará extensión. A continuación se pregunta si se desea tratar todas las tablas como entidades de sólo lectura, es decir, como si fueran vistas, a lo que habrá que responder S o N. Nota 2 La herramienta identificará aquellas entidades cuyo nombre cumpla la normativa de Erwin 7 de identificadores para vistas, y para esas entidades no generará las acciones de eliminar ni editar en el listado, el formulario de edición ni los tests unitarios. Lo siguiente será que la herramienta pregunte si deseamos generar cada una de las distintas capas de la aplicación, preguntas a las que tendremos que responder pulsando la letra S o N (mayúsculas o minúsculas indistintamente): - Generar Entidades de Dominio S/N - Generar los DAOs S/N - Generar los Servicios S/N - Generar la Fachada S/N Página 26 de 37

27 - Generar las pantallas JSF S/N - Mostrar los formularios en pop-ups (ver Nota 3) - Generar los Tests de JUnit S/N Nota 3 Si indica N en la opción ATENCIÓN: INDIQUE SI DESEA QUE LOS FORMULARIOS SE MUESTREN EN POP- UPS (S/N)", el formulario se mostrará en su propia página JSF, como ha ocurrido hasta la versión 1.5. Por otro lado, si indica S, el formulario detalle se mostrará en un pop-up, tanto para las acciones de editar como nuevo. El código generado difiere mínimamente al indicar esta opción. Caben destacar los siguiente cambios: Todas las acciones usadas en las páginas JSF son Ajax y se encuentran dentro de un único formulario (<h:form> en listaxxx.xhtml) Se creará un pop-up en cada página JSF de listado (popupformulario en listaxxx.xhtml) para mostrar el detalle de cada registro (formularioxxx.xhtml) en la acciones de Nuevo y Modificar Página 27 de 37

28 Después de seleccionar las opciones deseadas, la herramienta comienza a generar todos los ficheros, mostrando al final el resultado de la generación, así como un listado de todos los ficheros generados y/o modificados: Nota 4 Es importante revisar el log de la consola, porque en ocasiones se muestran advertencias sobre ficheros que no se han creado porque ya existían, o modificaciones que no se ha podido realizar. Fichero de Log de la generación de código En el directorio /generador se crea automáticamente un fichero llamado hibernate.reveng.log que contiene un log con todas las ejecuciones del generador de código. A leerlo asegurarse de estar leyendo la última ejecución ya que el log guarda todas. 3.6 COMPROBACIÓN DE CÓDIGO GENERADO Una vez ejecutada la herramienta, sólo queda comprobar que el código se ha generado correctamente. Para ello, debemos pulsar con el botón derecho sobre el proyecto XXXX_Web, y seleccionar la opción Refresh : Página 28 de 37

29 Podemos comprobar entonces que se han generado los ficheros indicados en el apartado Descripción del código que se genera, tanto Java como xhtml dentro de las carpetas correspondientes del arquetipo. Nota 1 En casos excepcionales es posible que algunos de los tests de JUnit no se ejecuten correctamente, en ese caso será necesario revisar los logs de ejecución para identificar los posibles errores y corregirlos. En tablas con Primary Key única y numérica, el generador de código asume que se cumple la normativa de Base de Datos y ERWIN V7, por lo que asume que existe una secuencia con la nomenclatura XXXX_S_NOMBRETABLA, que utilizan las entidades para crear nuevos objetos. Un fallo típico en los tests de JUnit es al tratar de insertar un objeto de algún tipo de datos para el cuál no existe la secuencia. Página 29 de 37

30 Nota 2 En tablas con foreign keys no nulas a otras entidades de dominio, la herramienta de generación de código genera el código de los Tests de JUnit, pero deja comentada la y por tanto el test no se ejecuta. En estos casos deberá modificarse el test manualmente, y posteriormente descomentar la anotación para que se ejecute el test. Para saber dónde hay que modificar el test, la herramienta deja un comentario // TODO: en las líneas concretas: Página 30 de 37

31 Nota 3 Puede observarse que para poder tratar las entidades de manera genérica en las pantallas de administración de catálogos, la herramienta de generación de código crea tres métodos anotados en las entidades de dominio. Estos métodos son: - getpkasstring y getpkfromstring: necesarios para identificar una entidad a través de una cadena de texto. - gettextolistavalores: Utilizado para mostrar un texto descriptivo de la entidad cuando se muestra dentro de una lista de valores y para buscar sobre ese campo en los formularios de búsqueda. Esta anotación indica que ese método no tiene que ser persistente. Página 31 de 37

32 3.7 COMPROBACION DE FORMATO DEL CÓDIGO GENERADO. Una vez generado todo el código y comprobado que se ha realizado correctamente debemos comprobar el formato de este. Para hacerlo, debemos ejecutasr el validador de Checkstyle y PMD de eclipse, para hacerlo, lo primero que debemos comprobar es que tenemos configurado eclipse con las los fichero de configuración de Checkstyle y PMD de ATLAS (Ver manual de configuración del entorno de desarrollo). Una vez comprobado esto, ejecutar la validación se realiza siguiendoestos pasos: 1. Ejecución de la validación de Checkstyle: botón derecho del ratón sobre el proyecto en la vista Project Explorer / Package Explorer, accediendo al menu Checkstyle y en este clickando en la opción Check Code With Checkstyle 2. Ejecución de la validación de PMD: botón derecho en el proyecto, seleccionamos el menu PMD y la opción Check Code With PMD. Página 32 de 37

33 3. Comprobación del resultado de las validaciones: al realizar estas validaciones, siempre que se encuentren errores, aparecen en las clases que tienen errores un indicador de error, indicador que se muestra tanto a nivel de paquete como de clase. 4. Además de estos indicadores en la vista de Project Explorer / Package Explorer, se puede abrir la vista Checkstyle violations donde se muestra una lista con los problemas encontrados en el código. Para PMD no tenemos ninguna vista especifica para comprobar los errores. 5. Corrección automatica de errores: los errores encontrados con las validaciones de Checkstyle y PMD, en la mayoria de ocasiones se solucionan con el formateador de código de eclipse. a. Antes de utilizar el formateador hay que comprobar que tenemos configurado el fichero de ATLAS para el formateador: i. Comprobación de la configuración del formateador de código de eclipse: entramos en la configuración de Java (Window>Preferences). En esta configuración accedemos a Java>Code Style>Formatter y comprobamos que tenemos en al Active profile el formateador de ICM. ii. Página 33 de 37

34 iii. Comprobación de la configuración del cleaner de eclipse: accedemos a la configuración de Java (Window>Preference) En esta navegamos a Java>Code Style>Clean Up y comprobamos que tenemos en al Active profile el limpiador de ICM.. b. Una vez comprobado que el formateador y el limpiador están correctamente configurados, accediendo a cada una de las clases en las que tengamos marcados errores de Checkstyle o PMD, debemos pulsar el botón derecho del ratón en el editor de código y seleccionar en el menu Source las opciones Format y Clean Up. Página 34 de 37

35 6. Una vez ejecutadas estas dos herramientas, debemos actualizar la información de Checkstyle y PMD repitiendo los pasos 1 y 2. Normalmente no debería quedar ningún error, pero en algunos casos es posible que queden errores. Si al realizar esta comprobación siguen apareciendo errores de Checkstyle o PMD, estos deben solucionarse manualmente. 3.8 EJECUCIÓN DE LA APLICACIÓN Por último, debemos de ejecutar Maven para compilar el proyecto (goals clean install ), y comprobar que los tests de JUnit generados se ejecutan correctamente. Después, procederemos a ejecutar la aplicación para comprobar que efectivamente se han generado las pantallas de mantenimiento de catálogos. La herramienta de generación automática de código genera una sub-opción de menú por cada catálogo, en la opción Mantenimiento de Catálogos : Página 35 de 37

36 Página 36 de 37

37 4 USO INCREMENTAL DE LA HERRAMIENTA La herramienta está pensada para poderse ejecutar incrementalmente, de manera que se puedan generar las pantallas correspondientes a una serie de tablas, y en el futuro cuando se añadan tablas nuevas volverse a ejecutar con las nuevas. Así, antes de introducir una modificación en el código, la herramienta comprueba que dicha modificación no exista ya, de forma que no realiza ninguna modificación dos veces. Nota La incrementalidad de la herramienta de generación de código es incrementalidad a nivel de tabla, no a nivel de campo. Si se modifican las columnas de una tabla para la que ya se generó el código, es necesario eliminar primero manualmente el código anterior para que vuelva a generarse el código con los campos modificados, del mismo modo si se elimina alguna propiedad del fichero hibernate.reveng.properties, la herramienta volverá a solicitar la información, pero sólo se modificarán el código si los ficheros afectados han sido eliminados previamente. Página 37 de 37