Manual Codgen GvHidra 0.5.0

Captulo 1.
MOSKitt: Generacin de cdigo gvHidra

Tabla de contenidos
Introduccin ................................................................................................................. 1 Arquitectura y modelos .......................................................................................... 2 Modelos principales .............................................................................................. 3 Otros modelos ...................................................................................................... 3 Descripcin de un caso de estudio: Desarrollo de una aplicacin de facturacin. ........................ 5 Tutorial: Proceso de desarrollo de aplicaciones con MOSKitt, pasos a seguir. ........................... 6 Presentacin de todo el proceso de construccin de una aplicacin con MOSkitt ................ 6 Tarea 1: Especificar la Lgica de Negocio: Modelo UML2 ......................................... 10 Tarea 2: Obtener el modelo de Base de Datos: Transformacin UML2DB ...................... 11 Tarea 3: Completar el Modelo de Base de Datos ....................................................... 12 Tarea 4: Generar los scripst DDL ........................................................................... 13 Tarea 5: Generar la Base de Datos ......................................................................... 13 Tarea 6: Especificar la Interfaz de Usuario: Crear el modelo de Sketcher ........................ 14 Tarea 8: Obtener el modelo UIM: Transformacin Sketcher2UIM ................................ 23 Tarea 9: Completar el modelo UIM ........................................................................ 24 Tarea 10: Generar el cdigo gvHidra: Transformacin Sketcher2gvHidra ....................... 26 Otros escenarios (Tarea 1b): Cuando al empezar ya tenemos una Base de Datos .............. 30 Resultado de la generacin: Paseo por la aplicacin generada y su ejecucin ........................... 32 Resultado de la generacin: Paseo por los elementos ha creado el generador ........................... 34 Los archivos que se han generado: estticos y generados ............................................ 34 Elementos generados por MOSKitt en estos archivos ................................................. 34 Nombre que le da el generador a algunas variables que genera ..................................... 35 Proteccin del cdigo: Estrategias utilizadas por MOSKitt para respetar los cambios realizados por el desarrollador. .............................................................................. 36 Cmo tengo que definir mis modelos para que los entienda el generador? ............................. 39 Tareas 1 y 3: Los modelo UML2 y de Base de Datos. ................................................ 39 Tareas 6 y 9: Los modelos Sketcher y UIM ............................................................. 40 Resolucin de errores comunes: Por qu no me ha generado esto o aquello? .......................... 57 Cmo resolver errores que ocurren al ejecutar la transformacin para generar el cdigo ......................................................................................................................... 57 Cmo resolver errores ocurridos al ejecutar la aplicacin generada ............................... 58 Anexos ...................................................................................................................... 62 Visin detallada de la estructura de las Plantillas en el Sketcher ................................... 62 Lista completa de etiquetas que reconoce el generador. .............................................. 69 Descripcin detallada del cdigo gvHidra generado ................................................... 71 Versin pdf de este documento.
Introduccin
El mdulo Codgen-gvHidra de MOSKitt proporciona la generacin semi-automtica de aplicaciones gvHidra. Hablamos de generacin semi-automtica para indicar que el cdigo de la aplicacin gvHidra que se obtiene tras la generacin deber ser completado por los desarrolladores. Desde una visin global, la generacin consiste en un conjunto de transformaciones de modelos hasta llegar al cdigo final.
Arquitectura y modelos
Una aplicacin web sigue una arquitectura N-Capas, cuyos componentes, de forma genrica, son: Capa de Presentacin Capa de Lgica de Negocio (puede incluir servicios). Capa de Persistencia de Datos (puede incluir una capa de gestin de los datos). Especificar una aplicacin web consiste en especificar cada uno de estos componentes. En la siguiente figura se muestran qu modelos son necesarios para especificar cada uno de ellos:
Figura 1.1.
Las aplicaciones gvHidra por ser aplicaciones web seguirn el esquema anterior. En gvHidra se implementa una arquitectura N-Capas concreta como es la que define el patrn MVC (Modelo/Vista/ Controlador). El Modelo maneja el comportamiento y las estructuras de datos que maneja la aplicacin. La Vista es la capa de presentacin que proporciona al modelo una interfaz con el usuario. El Controlador responde a eventos, usualmente acciones que el usuario invoca desde la vista y las traslada al modelo convirtindolas en solicitudes compresibles por ste.
Figura 1.2.
Siguiendo este esquema, los modelos necesarios para especificar una aplicacin en gvHidra y que por tanto sern la entrada del generador de cdigo en MOSKitt son: Modelo UML2 Modelo de BD (Base de Datos). Modelo Sketcher + Modelo UIM (User Interface Model)
MOSKitt: Generacin de cdigo gvHidra El responsable de construir todos estos modelos es el analista/diseador, sin embargo, el principal consumidor del cdigo que se obtiene como resultado es el desarrollador, que es quien deber completarlo. Es por tanto muy importante que el desarrollador reciba todo el soporte necesario para explorar los modelos e identificar qu partes del cdigo generado son las que deber completar. A continuacin se detalla cada uno de ellos.
Modelos principales
En el modelo UML2 se especifica principalmente el Modelo: la lgica del negocio y las estructuras de datos que deben ser persistidas en el sistema en la Base de Datos representado por el modelo de BD. En el modelo Sketcher se especifica principalmente el aspecto que tiene la Vista y parte de su relacin con el Modelo a travs de sus referencias al modelo UML2. La informacin correspondiente al Controlador se define a caballo entre los modelos Sketcher y UIM. A travs del Sketcher se puede deducir un modelo inicial UIM y, para comportamientos por defecto del framework, el analista no necesita especificar nada ms en l. La especificacin en el Sketcher se hace partiendo de las plantillas de la Gua de Estilo de la CIT, las cuales ya estn modeladas y listas para ser utilizadas por los analistas. El comportamiento bsico del Controlador y la Vista asociado en gvHidra a las plantillas est incorporado directamente en el generador de cdigo que es quien sabe interpretarlas. De este modo, si el framework gvHidra evoluciona haciendo que las mismas plantillas tengan alguna variacin en su interpretacin, dar lugar a una nueva versin del generador. Sin embargo, la definicin de las plantillas slo cambiar cuando lo haga la gua de estilo. Si el analista necesitase especificar cambios en el comportamiento que por defecto tiene asociado el framework a cada plantilla, deber hacerlo en el Sketcher o en UIM segn el caso, siguiendo las normas establecidas por la metodologa que use la organizacin en cada caso. Estos cambios sern implementados ms tarde por los desarrolladores a partir del cdigo obtenido del generador.
Otros modelos
MOSKitt da soporte a una estrategia de generacin de cdigo siguiendo DSDM (Desarrollo de Software Dirigido por Modelos). En esta aproximacin, los modelos dejan de ser slo documentacin para convertirse en piezas fundamentales en la generacin de cdigo. Unos modelos son transformados en otros hasta alcanzar en cdigo final.
Figura 1.3.
Por tanto, la generacin de cdigo es una transformacin ms, la cual, como el resto de transformaciones MOSKitt puede configurarse para que el resultado se adece a las necesidades de
MOSKitt: Generacin de cdigo gvHidra cada aplicacin (por ejemplo, se deber indicar qu partes se quieren transformar, con qu cadena de conexin, con qu modelos, etc...). Cada vez que se lanza una transformacin en MOSKitt, quedan trazados los modelos de entrada y de salida. Esto significa que se crear un modelo de trazas (un fichero con la extensin .gvtrace) que permitir a MOSKitt navegar entre todos aquellos modelos que estn trazados (por ejemplo, entre el modelo de UML2 y el de DB permitindole saber una determinada clase en qu tabla se ha transformado, etc...). En concreto, esta transformacin necesita que estn disponibles las trazas entre los modelos: UML2 y DB Sketcher y UIM Conviene saber esto ltimo para entender todos los artefactos que intervienen en la generacin y tener la precaucin de que todos ellos estn presentes en el proyecto del cual se va a generar el cdigo.
Descripcin de un caso de estudio: Desarrollo de una aplicacin de facturacin.

Vamos a seguir los pasos necesarios para desarrollar una aplicacin con MOSKitt siguiendo una aproximacin DSDM (Desarrollo de Software Dirigido por Modelos). Para ello en este manual se acompaar cada paso con su correspondiente ejemplo. En concreto, vamos a desarrollar una aplicacin de facturacin para una pequea empresa y vamos a explicar tambin cmo, una vez hemos llegado a generar cdigo, ste puede ser mantenido durante un proceso de desarrollo iterativo e incluso, una vez puesta en produccin la aplicacin, cuando sea necesario incluir cambios durante la fase de mantenimiento. En el modelado de la aplicacin aparecen cuatro elementos principales: Clientes Productos Facturas Lneas de Factura De forma muy sencilla podemos resumir los requisitos del siguiente modo: La aplicacin deber permitir el mantenimiento de todas estas entidades. Un cliente puede tener una o ms facturas. Cada factura, adems de informacin especfica de la factura, indicar en cada una de sus lneas la cantidad facturada de un producto concreto. Un producto puede aparecer en ms de una factura A lo largo del documento vamos a aplicar sobre este caso de estudio el proceso de desarrollo de software propuesto por MOSKitt.
Tutorial: Proceso de desarrollo de aplicaciones con MOSKitt, pasos a seguir.

Presentacin de todo el proceso de construccin de una aplicacin con MOSkitt
En este punto vamos a dar un repaso al proceso de desarrollo de software propuesto por MOSKitt para construir aplicaciones, en este caso aplicaciones gvHidra. El proceso est basado en la estrategia DSDM (Desarrollo de Software Dirigido por Modelos). Los mdulos que intervienen en el proceso son: MOSKitt-UML2: Este mdulo permite especificar modelos UML2 haciendo un uso intensivo de los Diagramas de Clases (tambin proporciona otros diagramas como son los de secuencia, actividad y estados, sin embargo, estos ltimos no son utilizados durante la generacin de cdigo). MOSKitt-DB: Este mdulo permite realizar ingeniera inversa de Bases de Datos (PostgreSQL, Oracle y MySQL), editar Modelos de Base de Datos y generar scripts DDL para la generacin de Bases de Datos a partir de los modelos editados. MOSKitt-umldb.transformations: Incluye las tranformaciones de UML2 a BD (a partir de ahora UML2DB) y de BD a UML2 (a partir de ahora DB2UML2).. MOSKitt-Sketcher: Mdulo que permite la definicin de interfaces de usuario guiadas por el diseo de su aspecto. Permite enlazar los diferentes elementos del Sketcher (widgets) con elementos del modelo de clases de UML2 (propiedades mtodos). Este modelo es la entrada de la generacin de cdigo y a travs de l se alcanzan el resto de los modelos utilizados para especificar la aplicacin. MOSKitt-codgen-gvHidra: Es el mdulo que proporciona la generacin de cdigo gvHidra en sus dos vertientes: generacin de prototipos (cdigo sin conexin a una Base de Datos) y generacin de aplicaciones (requiere conexin a una base de datos ya existente). A continuacin se muestra en un diagrama BPMN (Bussines Process Modeling Notation) los pasos que se deben seguir para obtener una aplicacin gvHidra con el generador MOSKitt. En el diagrama tambin se indica el reparto de tareas entre el rol de Analista Informtico y el de Desarrollador. En la cabecera de cada tarea se muestra el mdulo MOSKitt que nos proporciona la funcionalidad necesaria para llevarla a cabo. El objetivo principal de este manual es mostrar cmo utilizar el mdulo MOSKitt-codgen-gvHidra para, a partir de modelos MOSKitt, obtener cdigo gvHidra. Los perfiles a quienes va dirigido este manual son los de Analista y Desarrollador para que: Los analistas conozcan bien cmo deben construir los modelos para que el generador sepa interpretarlos. Los desarrolladores (1) sepan de dnde proviene cada una de las partes del cdigo generadas (de qu modelo ha extraido la informacin que le ha servido de base), (2) qu partes del cdigo son susceptibles de ser completadas o revisadas en funcin del modelo definido por el analista, (3) qu mecanismos les proporciona MOSKitt para explotar la informacin contenida en los modelos y, por ltimo, (4) qu mecansmos se deben utilizar para que MOSKitt respete los cambios realizados sobre el cdigo por los desarrolladores para que, cuanto los analistas modifiquen los modelos, sus cambios sean respetados. Este es el mdulo que hace de puente entre ambos roles y es muy importante que los dos conozcan el proceso completo para comprender mejor el trabajo y realizarlo as de una forma ms cmoda. Aunque en este manual nos centramos principalmente en este mdulo, consideramos oportuno incorporar informacin del resto de los mdulos que intervienen en el proceso para que quede ms claro. Por este motivo, aunque en el manual de usuario de cada uno de los mdulos MOSKitt puede
MOSKitt: Generacin de cdigo gvHidra encontrarse la ayuda completa, en este manual vamos a hacer un pequeo repaso al exponer el caso de estudio.
MOSKitt: Generacin de cdigo gvHidra Siguiendo el argumento expuesto en el punto relativo a Arquitectura y Modelos, el diagrama anterior indica que el analista debe especificar los modelos UML2, de Base de Datos (BD) y Sketcher. A partir del modelo de BD, el analista generar los Scripts DDL que lanzar a travs de un cliente de SQL (tambin disponible en MOSKitt) para construir el esquema de la base de datos de la aplicacin. Para que la especificacin de la interfaz de usuario realizada con el Sketcher est completa, debe relacionarse con los elementos del modelo UML2. De este modo, el Analista puede expresar aspectos como son: qu propiedades de las clases se van a mostrar/editar desde la interfaz y qu mtodos del negocio van a ser invocados desde sta. Una vez especificados los tres modelos, se lanzar la generacin de cdigo inicial de la aplicacin gvHidra. El generador, a partir de la informacin que va leyendo del sketcher1completa la informacin que necesita. Esto es debido a que el generador, a partir del Sketcher puede alcanzar el modelo de UML2 y desde este a su vez, obtener el de Base de Datos. Esto es posible debido a que todos los modelos en MOSKitt estn relacionados entre s de dos modos distintos: De forma explcita: El usuario explcitamente establece la relacin entre los modelos (es el caso de Sketcher y UML2). De forma implcita: a travs de un modelo de trazas que se genera cada vez que se lanza una transformacin. Este modelo MOSKitt indica en qu elemento se ha convertido cada elemento del modelo origen tras la transformacin (es el caso de UML2 y BD).
Una vez creada la base de datos, el cdigo generado puede ser desplegado en el entorno de desarrollo que los desarrolladores puedan completarlo. Para hacerlo, necesitarn la documentacin que le proporciona MOSKitt: Informe obtenido a partir del Sketcher que detalla el contenido de cada una de las interfaces (pantallas/informes) previstas en la aplicacin, relacionandolas con el resto de los modelos. Los propios modelos realizados por el analista: Modelo de UML2.
1
El generador tambin usa la informacin del modelo UIM (User Interface Model), aunque esto es transparente al usuario.
MOSKitt: Generacin de cdigo gvHidra Modelo de Base de Datos. Modelo de Sketcher. Modelo de UIM (opcionalmente). En muchas ocasiones las cosas no se empiezan de cero y se dispone ya de un esquema de bases de datos inicial que puede servir de base en el anlisis. A partir de la Base de Datos fsica es posible obtenerlo por ingeniera inversa y, a partir de este modelo de Base de Datos, mediante la transformacin DB2UML2 obtener un modelo UML2 que servir como base para iniciar el anlisis. En los siguientes puntos pasamos a revisar cada una de las tareas descritas en el punto anterior. Lo vamos a hacer siguiendo el caso de estudio de la aplicacin de facturacin.
Tarea 1: Especificar la Lgica de Negocio: Modelo UML2

A partir de los requisitos establecidos para el caso de estudio, el Analista, haciendo uso del mdulo MOSKitt-UML2 define el diagrama de clases en el que describe las entidades que intervienen en el Sistema de Informacin de facturacin, sus propiedades y sus mtodos. Asumimos el siguiente modelo de clases (modelo UML2) para la aplicacin de facturacin:
Notese que no se han definido mtodos en el diagrama de clases. Esto es debido a que en su primera versin, la aplicacin de facturacin contendr slo los mantenimientos de todas sus entidades sin ninguna necesidad adicional: slo inserciones, modificaciones y borrados (vamos a considerar stas como operaciones bsicas). Recursos de Entrada de la tarea: Recursos de Salida de la tarea: Catlogo de Requisitos Funcionales. Los recursos que se obtendrn a la finalizacin de esta tarea son: Modelo de UML2 con las clases del sistema de facturacin (facturacion.uml).
10
MOSKitt: Generacin de cdigo gvHidra Diagrama de clases (facturacion.uml_diagram).
Tarea 2: Obtener el modelo de Base de Datos: Transformacin UML2DB

El modelo de Base de Datos se obtiene a partir del modelo de UML2 a a travs de la transformacin UML2DB que proporciona el mdulo MOSKitt-umldb-tranformations. La transformacin se puede lanzar a travs del men contextual que nos muestra MOSKitt si nos situamos, en la vista del explorador de recursos (Resource Explorer) sobre el fichero con extensin .uml (contiene el modelo de UML2 a transformar). Una vez abierto el men contextual, sobre la opcin MOSKitt Transformations, elegir la subopcin UML2 Class Diagram to Database transformation (para ms informacin consultar el Manual de Usuario de la transformacin en la ayuda de MOSKitt). Es posible configurar la transformacin para que el Analista decida cmo debe ser la Base de Datos final, ya que no todos los elementos tiene una nica regla de transformacin asociada. En el caso de estudio de la aplicacin de facturacin vamos a realizar la siguiente configuracin para la transformacin: Las tablas debern incluir el prefijo fact_ en su nombre. La herencia Persona <- Cliente ser transformada en una nica tabla que contendr todas las propiedades de la clase padre Persona y las de la clase hija Cliente. Para ms detalles sobre las opciones de configuracin de la transformacin se deber consultar el manual de usuario de la transformacin en la ayuda de MOSKitt.
Recursos de entrada de la tarea:
La tranformacin tendr como entrada los siguientes recursos: Modelo de UML2 (facturacion.uml). Configuracin de la transformacin (facturacion_uml2db.transformationconfiguration).
11
MOSKitt: Generacin de cdigo gvHidra Recursos de salida de la tarea: Como resultado de la transformacin se obtienen los siguientes recursos: Modelo de base de datos (facturacion.sqlschema) Diagrama de base de (facturacion.sqlschema_diagram) datos
El modelo de trazas entre los elementos del modelo UML2 y los del modelo de BD (facturacion!_! facturacion!-!uml2db.gvtrace).
Tarea 3: Completar el Modelo de Base de Datos

Es posible que, una vez realizada la transformacin haga falta completar el diseo de la Base de Datos para incluir informacin especfica del modelo de Base de Datos y que no puede ser deducido a partir del modelo UML2, como por ejemplo: Roles, Usuarios y Permisos. ndices. Revisin de claves ajenas (para casos en los que, por ejemplo, dos claves ajenas de una misma tabla deban compartir alguno de sus campos etc...). Definicin de claves alternativas. etc...
Recomendacin: Siempre que sea posible especificar la informacin en el modelo de UML2 o en la configuracin de la transformacin debe hacerse as. Esto permite minimizar los cambios en el modelo destino (en este caso el de base de datos) lo cual hace que sea ms sencillo mantener sincronizados los modelos. Sobre todo ms adelante, cuando cambios en los requisitos provoquen modificaciones en los modelos. De todos modos, est soportado en MOSKitt que los modelos que se obtienen como resultado de una transformacin puedan ser sincronizados de forma automtica respetando los cambios que los analistas puedan haber realizado sobre ellos (ver el apartado sobre sincronizacin de modelos en el Manual de Usuario en la ayuda de MOSKitt). Recursos de entrada de la tarea: Modelo de base de datos (facturacion.sqlschema). Diagrama de base de (facturacion.sqlschema_diagram). datos
12
MOSKitt: Generacin de cdigo gvHidra Recursos de salida de la tarea: Como resultado de la tarea se obtienen los mismos recursos pero, en su caso, modificados por el usuario: Modelo de base de datos (facturacion.sqlschema). Diagrama de base de (facturacion.sqlschema_diagram). datos
Tarea 4: Generar los scripst DDL

Esta funcionalidad nos la ofrece el mdulo MOSKitt-DB. La transformacin se puede lanzar a travs del men contextual que nos muestra MOSKitt si nos situamos, en la vista del explorador de recursos (Resource Explorer) sobre el fichero con extensin .sqlschema (contiene el modelo de BD a transformar). Una vez abierto el men contextual, sobre la opcin MOSKitt Transformations, dependiendo del SGBD disponible elegir una de las siguientes opciones: PostgreSQL DDL generation from DB models Oracle8 DDL generation from DB models Oracle10 DDL generation from DB models MySQL5 DDL generation from DB models Al igual que el resto de transformaciones, sta tambin es configurable (para ms informacin sobre la generacin de scripts DDL con MOSKitt consultar el Manual de Usuario de MOSKitt). En nuestro caso de estudio asumimos que vamos a disponer de una base de datos PostgreSQL. Recursos de entrada de la tarea: La transformacin necesita los siguientes recursos como entrada: Modelo de base de datos (facturacion.sqlschema). Configuracin de la transformacin (facturacion_db2ddl.transformationconfiguration). Recursos de salida de la tarea: Como resultado de la transformacin se obtienen los siguientes recursos: Scripts ddl para la creacin de los objetos de la base de datos (facturacion_dll_postgres.sql). Scripts ddl para la creacin de los roles, usuarios y permisos sobre los objetos de la base de datos (facturacion_dll_postgres_Privileges.sql).
Tarea 5: Generar la Base de Datos

Para crear la base de datos se deben ejecutar los scripts DDL obtenidos en el paso anterior desde un cliente sql externo (squirrel, PgAdmin, SQL Developer etc...) o incluso desde el propio MOSKitt. A continuacin se indican los pasos a seguir para hacerlo desde MOSKitt: 1. En primer lugar necesitamos definir una conexin a la base de datos haciendo uso de la vista Data Source Explorer (para ms informacin consultar Manual de Usuario de Ingeniera Inversa en la ayuda de MOSKitt). 2. Una vez definida la conexin debemos activarla (sobre la conexin definida, en el men contextual seleccionar la opcin Connect).
13
MOSKitt: Generacin de cdigo gvHidra 3. Si hacemos doble click sobre alguno de los ficheros .sql que se han obtenido en el paso anterior (generacin de scripts DDL) se abre en MOSKitt el siguiente editor sql:
4. A continuacin seleccionamos la conexin sobre la que queremos crear la base de datos y sobre el editor, en el men contextual seleccionamos la opcin Execute All. 5. Por ltimo, se nos abrir la vista SQL Results en la cual podremos comprobar cmo ha ido la operacin. 6. Desde la propia vista Data Source Explorer podemos tambin explarar el nuevo esquema que acabamos de crear.
Tarea 6: Especificar la Interfaz de Usuario: Crear el modelo de Sketcher

Vamos a ver ahora cmo definir la interfaz de la aplicacin de facturacin con el mdulo MOSKittSketcher.
Tarea 6.1: Cmo crear un nuevo modelo de Sketcher.

Este mdulo lleva incorporadas las plantillas que modelan los patrones de interfaz definidos por la Gua de Estilo de la Consellera de Infraestructuras y Transporte (CIT). Una gua de estilo determina una forma muy concreta de construir las interfaces para las aplicaciones de una organizacin (en este caso la CIT). Estas plantillas estn implementadas en gvHidra y es sobre las que trabaja el generador. Para poder usar estas plantillas en el Sketcher, al crear un nuevo diagrama (File/New.../ MOSKitt Sketcher Diagram) se debe seleccionar la opcin Inicialize from template y en concreto, de la lista que aparece en el asistente, la opcin Patrones CIT para gvHidra con Sketcher(sketcher_gvhidra.sketcher_diagram) tal y como se muestra en la figura que hay a continuacin:
14
Al finalizar el asistente, se puede ver que el diagrama que acabamos de crear ya contiene un elemento que representa el men principal de la aplicacin.
Tarea 6.2: Como crear el Men Principal de la aplicacin

Haciendo doble click en la figura que representa al men de la aplicacin (CIT Menu Principal en el digrama de la figura anterior), se abrir una nueva pestaa en el editor para poder modificar el contenido de la ventana tal y como se muestra en la figura que aparece a continuacin:
15
Desde el editor podremos completar la configuracin del men. Para ello, vamos a especificar la siguiente informacin: El nombre de la aplicacin: para ello se debe sustituir la etiqueta DEMO por FACT FACTURAS2 Los submens correspondientes a los mdulos de la aplicacin: por defecto se crean tres enlaces (widgets de tipo Men item action) . Las propiedades que se deben tener en cuenta en estos elementos para generar cada entrada del men de la aplicacin son: Texto: El valor de esta propiedad ser el texto que aparecer en el submen de la aplicacin. Imagen: El texto ir acompaado por la imagen seleccionada en esta propiedad. Ventana Destino: Indica la navegacin de la entrada del men a una ventana concreta de la aplicacin. Desde la ventana de propiedades del widget se puede seleccionar una ventana ya existente cuando las haya (con el botn ...) o bien crearla directamente (con el botn +). En las figuras que aparecen a continuacin vamos a ver cmo especificar estas propiedades en el widget (si se necesita ms informacin sobre la creacin de mens consultar el manual de usuario del Sketcher en la ayuda de MOSKitt).
16
Tarea 6.3: Cmo crear una nueva ventana accesible desde el men de la aplicacin.
Siguiendo el con el paso anterior, si decidimos crear una nueva ventana, aparece el asistente que podemos ver en la siguiente figura.
En ella podemos ver que usando este mecanismo es posible crear la ventana siguiendo dos aproximaciones distintas: Crear una ventana que se ajuste a alguna de las plantillas cargadas al crear el modelo de Sketcher (disponibles en la vista MOSKitt Artifacts Library). Crear de cero una ventana vacia. Importante: De cara a la generacin de cdigo gvHidra utilizaremos la primera aproximacin ya que, como hemos indicado anteriormente, el generador slo sabe construir ventanas definidas a partir de estas plantillas. Utilizaremos la segunda estrategia (ventana vaca) cuando tengamos que especificar una ventana que no est an soportada por el framework o su plantilla an no est disponible en el Sketcher: Siempre podremos modelar aunque no podamos generar. Ms adelante se estudiar cada una de las plantillas disponibles y se explicar el por qu de la nomenclatura utilizada. De momento, para modelar la ventana de Mantenimiento de Clientes de la aplicacin de facturacin vamos a seleccionar la primera de la lista (CIT 1C Tabular 1EI Registro) para crear una ventana Tabular-Registro de gvHidra. Esto es, una ventana que permite definir un filtro
17
MOSKitt: Generacin de cdigo gvHidra antes de lanzar una consulta, muestra los datos que obtiene como resultado en un formato Tabular (una tabla), pero al editar insertar cada uno de los elementos lo hace en formato Registro (un formulario). Una vez seleccionado la plantilla se crea la ventana como una copia de la misma y queda asignada automticamente como Ventana Destino del elemento del men que estamos editando.
En el diagrama principal del Sketcher aparece la nueva ventana con una flecha que representa el enlace entre las dos ventanas. La punta de flecha indica el sentido de la navegacin. Para cada ventana es recomendable especificar las siguientes propiedades: Id: La primera generacin de cdigo utiliza esta propiedad para definr el nombre de los archivos generados (archivos correspondientes a las vistas, las clases manejadoras etc....).
Si abrimos la ventana que acabamos de crear (haciendo doble click sobre la imagen que la representa en el diagrama principal) podemos ver que en este caso3 consta de tres paneles: Panel de Bsqueda. Panel de Consulta. Panel de Edicin/Insercin.
3
El contenido de la ventana depende de la plantilla seleccionada durante su creacin.
18
En estas imgenes se puede observar que tanto el panel de bsqueda como el de edicin/insercin se representan en formato Registro (formulario), mientras que el de consulta es Tabular (contiene un elemento Tabla disponible en la paleta del Sketcher). El analista partir de esta plantilla y la completar incluyendo en ella los widgets necesarios, disponibles en la paleta del Sketcher (TextBox, CheckBox, LixtBox etc...).
19
Tarea 6.4: Cmo relacionar los elementos del Sketcher con los del Modelo UML2
Para completar la especificacin de la interfaz necesitamos enlazar muchos de los widgets con elementos del modelo de clases. De este modo el analista podr indicar: Propiedades de las clases para indicar que un determinado widget debe mostrar o permitir editar su valor. Mtodos de las clases para indicar que desde un widget (normalmente un botn) podemos invocar ese mtodo desde la interfaz. Enumerados que deben ser ofrecidos desde una lista de valores etc... Para tener acceso a los elementos del modelo de UML2 en primer lugar tenemos que cargar este modelo como un nuevo recurso para el Sketcher. Para ello, debemos hacer click con el botn derecho sobre el lienzo del Sketcher y seleccionar la opcin Load Resource del men contextual. En este momento aparecer el siguiente asistente para cargar el modelo y, haciendo uso del botn Browse Workspace... debemos buscar el modelo de clases facturacion.uml (en nuestro caso de estudio) y finalmente pulsaremos OK. A partir de este momento todos los elementos del modelo UML2 sern accesibles desde el modelo de Sketcher de la aplicacin de facturacin.
A partir de este momento todos los elementos del modelo UML2 sern accesibles desde el modelo de Sketcher de la aplicacin de facturacin y podremos completar las propiedades necesarias de los elementos de cada panel.
En la imagen anterior se muestran las propiedades de un campo de texto. Para cada elemento debemos dar valor a las siguientes propiedades: Id: Identificador del widget (normalmente por claridad se indica el nombre de la propiedad de UML2 con la que se relaciona).
20
MOSKitt: Generacin de cdigo gvHidra Elemento Modelo: muestra con qu elemento del modelo de UML2 se relaciona el widget. Ruta Elemento Modelo: indica cmo se debe navegar en el modelo UML2 para alcanzar la informacin a mostrar. Vamos a ver su utilidad con un ejemplo: Si selecciono la propiedad nif de la clase Cliente estaremos indicando que en la interfaz se van a mostrar todos los clientes y, para cada uno de ellos su nif. Sin embargo, si selecciono la misma propiedad, pero navegando desde la clase factura (a travs de la asociacin que tengo definida), estar indicando que lo que voy a mostrar es slo el nif del cliente de la factura. Para ms informacin sobre todos los elementos disponibles en la paleta del Sketcher y sus propiedades consultar el manual de usuario del Sketcher en la ayuda de MOSKitt.
Tarea 6.5: Cmo completar la especificacin de la Interfaz de Usuario

Poco a poco iremos completando la especificacin de todos los elementos que forman parte de la interfaz correspondiente a la primera ventana del caso de estudio: Mantenimiento de Clientes. En el punto anterior hemos visto un ejemplo con los campos de texto (TextBox) y con elementos de este tipo hemos completado el Panel de Bsqueda de la Ventana de Mantenimiento de Clientes de la aplicacin de facturacin que estamos utilizando como ejemplo. En l hemos indicado que vamos a poder buscar por el valor de tres propiedades de los clientes: NIF Nombre Apellidos En la siguiente figura podemos observar en el extremo superior izquierdo de los campos de texto que aparece el smbolo D para indicar que ya est definida la relacin con el modelo UML2 (modelo de Datos). Para saber con qu elemento de UML2 se ha relacionado el widget debemos ir a la pestaa de propiedades y consultar las propiedades Elemento Modelo y Ruta Elemento Modelo descritas anteriormente.
Otros elementos personalizables son las etiquetas (Label), ttulos de las ventanas, botones, etc...Todo eso se ver con ms detalle en su apartado correspondiente (para ms informacin sobre todos los
21
MOSKitt: Generacin de cdigo gvHidra elementos disponibles en la paleta del Sketcher y sus propiedades consultar el manual de usuario del Sketcher en la ayuda de MOSKitt). En la siguiente figura podemos ver el panel de edicin/insercin el cual se visualiza en formato Registro (un formulario):
En l, la especificacin de los campos de texto se completa del mismo modo a como lo hemos hecho en el Panel de Bsqueda para indicar los campos del filtro:
Por ltimo, nos faltara especificar el Panel de Consulta el cual tiene un formato Tabular (contiene una tabla). En este caso, las columnas de la tabla adems de las propiedades que tienen los campos de texto, tienen la propiedad Texto, que determina la cadena que se debe mostrar como cabecera de la misma en la aplicacin (en el ejemplo NIF, Nombre, Apellidos y Telfono). Para ms informacin sobre todas y cada una de las propiedades de los widgets consultar el Manual de Usuario del Sketcher en la Ayuda de MOSKitt.
22
Podemos ver la propiedad Texto que aparece en estos elementos para indicar el ttulo de la cabecera de la columna:
Del mismo modo que hemos completado la ventana de Mantenimiento de Clientes iremos completando el resto de ventanas, seleccionando para cada caso, la plantilla de la gua de estilo correspondiente: Mantenimiento de Productos segn la plantilla CIT 1CEI_Tabular. Alta masiva de Productos segn la plantilla CIT 1I AltaMasiva. Mantenimiento de Facturas segn la plantilla CIT MD (Maestro Detalles).
Tarea 8: Obtener el modelo UIM: Transformacin Sketcher2UIM

Para generar el cdigo gvHidra, el generador de cdigo tiene en cuenta la informacin de los siguientes modelos: El modelo Sketcher. El modelo UIM. El modelo UML2 referenciado desde el Sketcher.
23
MOSKitt: Generacin de cdigo gvHidra El modelo de Base de Datos trazado con el de UML2. En la mayora de los casos el analista slo definir el modelo del Sketcher y el de UIM lo generar de forma automtica lanzando una transformacin especfica para ello: Sketcher2UIM. Para hacerlo nos tenemos que situar sobre el modelo de Sketcher (facturacion.sketcher_diagram) y en el men contextual seleccionar el submen MOSKitt Transformations/Sketcher to UIM (para ms informacin sobre la transformacin ver Manual de Usuario en la ayuda de MOSKitt). Al completar el asistente aparecen tres archivos nuevos en el proyecto, el modelo y diagrama de UIM, y el modelo de trazas entre UIM y Sketcher. Recursos de entrada de la tarea: Recursos de salida de la tarea: Modelo de (facturacion.sketcher_diagram). Sketcher
Como resultado de la transformacin se obtienen los siguientes recursos: Modelo de UIM (facturacion.uim). Diagrama de UIM (facturacion.uim_diagram). Modelo de trazas entre el modelo de Sketcher y el modelo de UIM generado (facturacion!_!facturacion!-! sketcher2uim.gvtrace).
En el siguiente apartado se va a explicar el por qu de la existencia del modelo UIM y su relacin con el modelo Sketcher en la especificacin de la Interfaz de Usuario.
Tarea 9: Completar el modelo UIM

En este apartado vamos a exponer la importancia del Modelo UIM en el marco de la definicin de interfaces de usuario. Si an estis viendo por primera vez MOSKitt a lo mejor os parece que ese apartado es un poco rollo. Si es as os lo podis saltar, no obstante os recomdendamos que ms adelante, cuando estis ms familiarizados con el proceso propuesto por MOSKitt volvais a l. Seguramente entonces veis que s que os aclara muchas cosas respecto a Sketcher/UIM. Antes de empezar vamos a hacer algunas puntualizaciones sobre cmo MOSKitt propone que se aborde el uso de ambos modelos: Cuando un usuario empiece a utilizar MOSKitt es muy probable que slo haga uso del Sketcher pues la definicin de interfaces de usuario con este mdulo es mucho m intuitiva. Sin embargo, es importante entender qu limitaciones plantea el Sketcher a la hora de definir las pantallas/ formularios de las aplicaciones y cmo UIM resuelve en la mayora de los casos estos problemas de expresividad. An as, en MOSKitt se ha enriquecido la expresividad del Sketcher para que el uso de UIM no sea imperativo en la definicin de interfaces (al menos que no lo perciba as el usuario). La idea es: Con UIM lo puedes expresar casi todo, pero usar Sketcher es ms fcil. Vamos a intentar llegar a un porcentaje bastante elevado en la definicin de las interfaces con el sketcher y dejamos UIM para los casos ms complejos. Al principio de la implantacin de MOSKitt, los analistas prefieren completar el modelo de Sketcher con comentarios y anotaciones. Estas anotaciones se incluyen en el campo Descripcin de los elementos del Sketcher (disponible en la pestaa de propiedades) siguiendo unas reglas comunes a toda la organizacin. Sin embargo, a medida los usuarios vayan conociendo la herramienta llegar un momento en el que el uso de UIM no les resulte tan costoso como al principio y se animen a abordar el completar las interfaces con este lenguaje.
24
MOSKitt: Generacin de cdigo gvHidra UIM no es ambigo como sucede con cualquier descripcin textual, por tanto UIM puede ser procesado con el generador y, por este motivo, todo aquello especificado en UIM es susceptible de ser incorporado antes o despus en la generacin de cdigo.
Diferencias entre Sketcher y UIM

Os hemos explicado que es mejor incorporar UIM cuando los usuarios estn ms familiarizados con MOSKitt. Ahora os queremos aclarar qu diferencias hay entre ambos modelos: UIM permite definir una interfaz desde un punto de vista abstracto, por eso las figuras que se usan para representar los elementos de la interfaz no aportan ninguna informacin sobre cual debe ser su apariencia en la interfaz de la aplicacin final. Un diagrama de UIM es similar a un diagrama de clases y en l podemos ver sobre todo "cajas" etiquetadas que contienen elementos y se relacionan unas "cajas" con otras. Una interfaz especificada con UIM se puede representar de muy diversas formas/aspectos, o lo que es lo mismo, puede implementarse en diferentes plataformas (un cliente ligero, un cliente rico, un mvil etc...). Por el contrario, con Sketcher podemos especificar una interfaz de forma muy concreta. Esto significa que cuando definimos una interfaz con Sketcher ya estamos tomando decisiones sobre qu aspecto debe tener y qu comportamiento para que se ajuste a una plataforma concreta: ya estamos pensando en un navegador, en un telfono mvil, en un cliente rico etc..... Estamos decidiendo qu widgets va a contener mi interfaz y dnde los voy a colocar y adems estoy obteniendo una representacin bastante fiel de cmo va a ser mi interfaz definitiva. Por todo esto, especificar interfaces con el Sketcher resulta muy intuitivo y los usuarios casi sin consultar el manual se sienten cmodos haciendo esta parte del trabajo. En la figura que aparece a continuacin podemos ver el aspecto que tiene una interfaz descrita con UIM y con Sketcher.
Sin embargo, una vez hayamos terminado de "pintar" la interfaz nos daremos cuenta de que nos hace falta decir algunas cosas ms. Es decir, si como analistas, le pasamos una interfaz "pintada" con el Sketcher a uno de nuestros desarrolladores, estamos seguros de que les tendremos que dar ms informacin para que puedan desarrollar de esa pantalla o informe. Algunas de las cosas que tendremos que decirles son: Esta interfaz se ajusta a alguna plantilla de gvHidra? Cada text box, qu propiedad de qu clase o, lo que es lo mismo, qu campo de qu tabla tiene que mostrar y/o permitir editar?. Todos los campos son siempre editables?. Un botn de la interfaz a qu metodo de negocio debe invocar? cuales son sus parmetros de entrada? dnde debe mostrar el resultado si tiene parmetros de salida? Seleccionar un determinado valor en una lista tiene algn comportamiento asociado en la interfaz? etc...
25
MOSKitt: Generacin de cdigo gvHidra Bueno, pues estos son los tipos de cosas que puedo decir con UIM y que habitualmente no se puede decir en un simple "pintador". No obstante, Sketcher no es un simple pintador sino que ha sido diseado para que haga de puente entre el usuario y UIM. Cmo?, permitindo especificar desde Sketcher algunas de estas caractersticas, ms propias de UIM para facilitar de este modo al analista el uso de UIM (de hecho, en muchos casos puede incluso obviarlo). Cul es la informacin propia de UIM que ya puedo adelantar desde el Sketcher?. Principalmente la siguiente: A qu plantilla de gvHidra se debe ajustar mi interfaz. El valor de qu propiedades muestro en los widgets y debo permitir editarlos. Qu mtodos de negocio invoco desde la interfaz (normalmente al pulsar un botn). Qu widgets son editables/visibles/obligatorios siempre. Qu widgets son editables/visibles/obligatorios para cada operacin (en la insercin, borrado, edicin etc...). Navegacin entre ventanas. Entonces.... para qu quiero UIM?. UIM es necesario porque es quien realmente aporta todos los conceptos necesarios para especificar una interfaz de usuario: su estructura y su comportamiento. Aunque mucha de la informacin necesaria ya se ha dicho en Sketcher, no es suficiente, lo podis comprobar revisando el campo Descripcin de muchos de los elementos del Sketcher. Si en este campo hay informacin relativa al comportamiento de la interfaz pensad que esta informacin podra especificarse en UIM. An as, podemos generar aplicaciones sin que el usuario tenga que llegar a abrir un modelo UIM. Recursos de entrada de la tarea: Modelo de UIM (facturacion.uim). Diagrama de UIM (facturacion.uim_diagram). Recursos de salida de la tarea: Como resultado de la tarea se obtienen (si procede) los mismos recursos pero actualizados por el usuario: Modelo de UIM (facturacion.uim). Diagrama de UIM (facturacion.uim_diagram).
Tarea 10: Generar el cdigo gvHidra: Transformacin Sketcher2gvHidra

Una vez hemos modelado la aplicacin ya podemos lanzar la transformacin para generar la versin inicial de nuestra aplicacin de facturacin. Como ya hemos comentado antes, para generar el cdigo gvHidra, el generador de cdigo tiene en cuenta la informacin de los siguientes modelos: El modelo Sketcher. El modelo UIM. El modelo UML2 referenciado desde el Sketcher. El modelo de Base de Datos trazado con el de UML2.
26
MOSKitt: Generacin de cdigo gvHidra Podemos lanzar la transformacin desde el modelo de Sketcher. Para ello, sobre el modelo (facturacion.sketcher_diagram) seleccionamos del men contextual el submen MOSKItt Transformations y de ste seleccionamos la opcin Generation of a gvHidra aplication (v.3.1.0). El asistente pide como parmetros de entrada los modelos Sketcher, UIM y una carpeta donde dejar el cdigo generado:
A continuacin se muestra la siguiente pgina en el asistente para seleccionar qu transformaciones quiero lanzar. En principio vamos a dejar ambas opciones marcadas y ms adelante explicaremos cmo funciona la transformacin para comprender mejor esta pgina.
De nuevo, por ser una transformacin MOSKitt es configurable. Es ms, en este caso siempre debemos configurarla para indicarle al menos la cadena de conexin a la base de datos donde residen los datos de la aplicacin (esto ltimo implica que para esta transformacin, no hay una configuracin por defecto satisfactoria y el usuario siempre deber crear una).
27
MOSKitt: Generacin de cdigo gvHidra El editor de configuracin nos muestra los patrones de configuracin para cada elemento configurable del modelo (ver manual de usuario de la transformacin en la Ayuda de MOSKitt para ms detalles). Vamos a explicar aqu brevemente cada uno de los patrones a configurar: Use Debug. Copy gvHidra Framework Files. Use Database. Apply Custom. Use Debug: permite configurar cadena de conexin a la base de datos y el nivel de debug interno de la aplicacin gvHidra (LOG_ALL, LOG_NONE, LOG_AUDIT, LOG_ERRORS). Para ms informacin sobre cuando es posible activar el nivel de debug consultar el manual de gvHidra.
Copy gvHidra Framework Files: Indica si el cdigo generado debe incluir el cdigo del ncleo del framework gvHidra o slo se debe generar el cdigo especfico de la aplicacin. Al menos la primera vez que se genera la aplicacin es necesario tenerlo activado. Si no se van a utilizar informes en la aplicacin, se puede desactivar el check que aade las libreras de jasper. Para ms informacin consultar los manuales de gvHidra y de Jasper Reports.
Use Database: permite indicar el modelo de Base de Datos que se debe tener en cuenta en la generacin.
28
MOSKitt: Generacin de cdigo gvHidra Vamos a explicar brevemente por qu hace falta incluir este dato si, como hemos dicho antes, el modelo UML2 y el de BD estn relacionados por medio de las trazas: A partir del modelo de Sketcher inicial podemos alcanzar el modelo de UML2 pues estos han sido relacionados explcitamente por el usuario. Ahora bien, a partir del modelo de UML2 es posible que el usuario haya decicido lanzar la transformacin UML2DB muchas veces (por probar o por el motivo que sea), dando lugar a varios modelos de BD y a sus correspondiente trazas. Para evitar ambigedades con respecto a cual de ellos es el definitivo, MOSKitt le pide al usuario que sea l quien lo determine. Para seleccionar el modelo de base de datos, lo primero que hay que hacer es cargar el recurso pulsando el botn
Una vez cargado el recurso hay que navegar al final del panel y completar la propiedad Source Database Model.
Apply Custom: Las aplicaciones gvHidra tienen asignado un tema o customizacin en el que se especifica la apariencia de la aplicacin entre otros aspectos (para ms informacin sobre los Custom consultar documentacin del framework gvHidra). Si se dispone de un custom personalizado se deber indicar como parmetro en este patrn.
29
MOSKitt: Generacin de cdigo gvHidra Por ltimo, cada una de las ventanas creadas se puede configurar para indicar si se desea que sean o no generadas (por defecto, estar configurado para que se generen). Sobre todo en generaciones posteriores, tal vez no interese que el generador vuelva a generar cdigo que ya est terminado e incluso ya en produccin.
Una vez completada la configuracin podemos completar la transformacin (desde el botn Execute Transformation que aparece en el editor de configuracin). Una vez terminada la generacin, el asistente indica si todo ha ido bien o los errores ocurridos en su caso. En caso de error, la generacin se detiene debe comprobarse que los modelos cumplen con los requisitos que exige el generador de cdigo (ver ms adelante en este manual la seccin que trata sobre que propiedades deben cumplir los modelos de entrada para que los sepa interpretar el generador).
Otros escenarios (Tarea 1b): Cuando al empezar ya tenemos una Base de Datos
Volvemos ahora un poco al principio de la seccin 3 en la que estamos describiendo cada uno de los pasos que se deben seguir para generar aplicaciones con MOSKitt. Hasta ahora hemos visto un camino en el proceso en el que al empezar no tenamos nada y empezbamos de cero a definir los modelos. Sin embargo, pueden haber otro escenarios. En muchos casos es habitual disponer de una base de datos inicial a partir de la cual podemos llegar a obtener un modelo UML inicial para nuestro anlisis. En este escenario los pasos a seguir para conseguir este modelo UML2 sern:
30
MOSKitt: Generacin de cdigo gvHidra 1. Obtener el modelo de BD a partir de Ingeniera Inversa de la Base de Datos fsica. 2. Lanzar la transformacin BD2UML2 para obtener el modelo de UML2 inicial.
Ingeniera Inversa de la Base de Datos

Es posible obtener el modelo UML2 correspondiente a partir de un modelo de base de datos resultado de realizar una ingeniera inversa (para ms informacin consultar Manual Usuario de MOSKitt-DB). Vamos a ver con un poco ms de detalle este paso sobre el caso de estudio de la aplicacin de facturacin. Los pasos a seguir seran los siguientes: 1. En primer lugar es necesario crear en MOSKitt-DB, a travs de la vista Data Source Explorer una conexin con la base de datos donde se encuentra el esquema del que queremos obtener la Ingeniera Inversa (vamos a suponer en este caso que se trata de una conexin a una base de datos local postgresql a travs de JDBC).
Nota: El nombre de las tablas es el que tienen en la base de datos, que en este caso incluyen un prefijo comn.
31
Transformacin DB2UML : Obtener un modelo UML2 a partir del modelo de base de datos
A partir de un modelo de base de datos hay que construir un modelo de clases UML2. Esto se har automticamente a partir de la transformacin de Base de datos a UML2 (DB2UML) (Ver Manual de Usuario para ms detalles acerca de la transformacin). Como resultado se obtienen dos modelos, uno UML2 y otro que contiene las trazas entre los modelos de base de datos y UML2. Atencin!, el modelo de trazas puede estar oculto. El modelo UML2 ser el utilizado para el anlisis de la aplicacin, mientas que el de base de datos y el de trazas son dispensables.
Resultado de la generacin: Paseo por la aplicacin generada y su ejecucin

Una vez completados los pasos del punto 3 habremos obtenido una aplicacin gvHidra. Para ver el resultado habr que localizar la carpeta con el cdigo generado en la ruta de publicacin del servidor. Una vez desplegada la aplicacin en el servidor podremos acceder a ella desde el navegador, para ello introducir la direccin de la misma siguiendo con el formato: http://direccion_servidor/ruta_a_aplicacion/ nombre_carpeta_aplicacion A continuacin, en la pantalla debe aparecer un cuadro de login esttico. Para comprobar la aplicacin podemos probar con el usuario invitado y la contrasea 1.
32
MOSKitt: Generacin de cdigo gvHidra Al pulsar el botn Login accederemos al men principal de la aplicacin de facturacin que aparece en la figura siguiente. En ella se podemos ver a la izquierda el men relativo a los Mdulos principales de la aplicacin con las entradas que nos llevan a las pantallas que han sido definidas con el Sketcher (Mantenimietno de Clientes).
En el ejemplo anterior se ha creado una ventana Tabular-Registro de tres paneles, y es lo que debe aparecer al pulsar en el enlace Mantenimiento Clientes. La pantalla de entrada es el filtro de la ventana.
Al pulsar el botn Buscar se visualiza el listado de datos que cumplen los requisitos especificados. En este ejemplo se muestran datos porque la base de datos ya exista antes de empezar con el anlisis.
Al pulsar el botn Nuevo o Modificar se visualiza el panel de Edicin/Insercin de datos.
33
Al pulsar el botn guardar se vuelve a visualizar el listado de clientes, que ahora incorpora los datos del nuevo.
Resultado de la generacin: Paseo por los elementos ha creado el generador

Tras la ejecucin de los pasos del punto 3, se obtiene una aplicacin independiente. Esto quiere decir que tanto los archivos del framework como los de la propia aplicacin son proporcionados por la transformacin. Gran parte de los archivos del framework se mantienen invariantes entre aplicaciones. A partir de esta idea, se clasifican los archivos resultantes en dos tipos: estticos, que son totalmente idnticos sea cual sea la aplicacin a crear, y los generados, que se construyen a partir de los modelos de entrada y dependen de su contenido.
Los archivos que se han generado: estticos y generados

Archivos Estticos Son aquellos que se mantienen invariables generacin trs generacin (son independientes de los modelos de entrada). Entre ellos se encuentran principalmente los archivos del "ncleo" de gvHidra. As se crea prcticamente todo el contenido de la carpeta igep, las clases jasper para mostrar informes y algunos archivos del directorio raz de la aplicacin. Tambin se generan automticamente los archivos include.php y mappings.php, cuyo contenido se ha personalizado y ya no tienen contenido variable. El contenido variable se encuentra en los archivos include y mapping que ahora se generan especficamente para cada ventana (ver ms adelante refactorizacin del cdigo generado). Archivos Generados El contenido de estos archivos es dependiente de los modelos de entrada.
Elementos generados por MOSKitt en estos archivos

A partir de los modelos de entrada, el generador crea los siguientes elementos: Configuracin a nivel de aplicacin. Clases manejadoras. Vistas.
34
MOSKitt: Generacin de cdigo gvHidra Plantillas. Mappings. Includes. Men principal.
Nombre que le da el generador a algunas variables que genera

Los desarrolladores tambin necesitan saber el esquema que sigue el generador para establecer el nombre de las variables que genera. El nombre se formar siguiendo las siguientes expresiones:en los paneles EDI con el nombre del panel ms el nombre de elemento del modelo al que referencia el elemento del Sketcher y su el nombre de la clase (menos en el panel FIL). Panel LIS: concat ('lis',nompropiedad) Panel FIL: concat('fil',nompropiedad,'_',nomclase) Panel EDI: concat('edi',nompropiedad,'_',nomclase) Vamos a verlo con un ejemplo: Si definimos una ventana para el mantenimiento de los Clientes haciendo uso de la plantilla CIT 1C_1EI Tabular-Registro (se corresponde con la plantilla Tabular-Registro de gvHidra) y modelamos lo siguiente: En el panel Bsqueda definimos un filtro restringuir los clientes segn las propiedades Nif y Nombre. En el panel Consulta definimos que la informacin que vamos a ver de cada cliente son las propiedades Nif, Nombre y Apellidos. En el panel Edicin/Insercin definimos que, para ambas operaciones vamos a editar de cada cliente las propiedades Nif, Nombre y Apellidos. Las variables en cada panel gvHidra seran: En el panel bsqueda (FIL) tendremos las variables: filNif filNombre En el panel consulta (LIS) tendremos las siguientes variables: lisNif_Cliente lisNombre_Cliente lisApellidos_Cliente En el panel edicin/insercin (EDI) tendremos las siguientes variables: ediNif_Cliente ediNombre_Cliente ediApellidos_Cliente
35
MOSKitt: Generacin de cdigo gvHidra La localizacin y el tamao del elemento vendr dada por las coordenadas X e Y y su tamao dentro del panel. No obstante, existen propiedades en el Sketcher para modificar y forzar estos valores a los que considere el usuario.
Proteccin del cdigo: Estrategias utilizadas por MOSKitt para respetar los cambios realizados por el desarrollador.
Uno de los principales temas a resolver cuando se genera cdigo de forma automtica es el tratamiento de las modificaciones manuales que ha realizado el desarrollador cuando, debido a cambios en los modelos, debemos regenerar el cdigo. Como hemos dicho al principio del manual, MOSKitt proporciona una generacin semi-automtica de cdigo, lo cual implica que en la mayora de los casos, los desarrolladores debern completar el cdigo para terminar la aplicacin. En la gran mayora de los casos, stos cambios deben mantenerse a la vez que se debe incorporar en el cdigo los cambios originados por los cambios en el modelo. Para hacer esto, MOSKitt utiliza dos tcnicas diferentes.
Estrategia 1: Refactorizacin de cdigo

Las clases manejadoras se han refactorizado en una jerarqua de herencia de tres clases.
Refactorizacin de las clases Manejadoras: Herencia

Las clases manejadoras se han refactorizado en una jerarqua de herencia de tres clases.
Tal y como puede verse en la figura anterior, la clase manejadora ahora se convierte en tres clases:
36
MOSKitt: Generacin de cdigo gvHidra La ClaseManejadora_SK: Extiende a la clase manejadora gvHidra_Form_DB que proporciona el framework (contiene el comportamiento general de un mantenimiento comn inserciones, modificaciones y borrados- contra un SGBD relacional). Contiene al contructor de la clase manejadora y gestiona principalmente la informacin de la base de datos que maneja la ventana y establece el matching entre los campos de la tpl y los de la base de datos. La ClaseManejadora_SKUI: Extiende a la ClaseManejadora_SK. A partir de los campos definidos en la interfaz y del tipo de datos de las propiedades UML con las que se relaciona, define los tipos de datos para cada panel de la ventana. Estas dos clases son siempre generadas por MOSKitt y por tanto, no deben ser modificadas por el desarrollador gvHidra, quien slo modificar: La ClaseManejadora propiamente dicha: extiende a la ClaseManejadora_SKUI. En ella se sobrescribir todo aquello que considere oportuno el desarrollador para incluir lo que no haya podido ser generado por MOSKitt (se asignan/modifican las propiedades de la clase y se definen los mtodos de la misma). Las clases manejadoras estn localizadas dentro de la carpeta actions, en una subcarpeta que toma el nombre de la propiedad Id de la Ventana. Destro de esta carpeta encontraremos siempre una carpeta denominada skeleton que contendr las clases manejadoras que no deben ser modificadas: ClaseManejadora_SK y ClaseManejadora_SKUI.
Divisin de algunos ficheros por ventanas (Includes y Mappings)

Tanto los includes como los mappings se han separado por ventanas. El archivo que antes contena toda la informacin ahora se limita a recorrer los nuevos archivos. El desarrollador podr encontrar en la carpeta include una subcarpeta includes y otra mappings. Ambas contendrn un archivo por cada pantalla: por ejemplo, para la pantalla MantemientoClientes encontraremos include/ includes/include_MantenimientoClientes.php y include/mappings/ mappings_MantenimientoClientes.php.
37
Estrategia 2: Zonas protegidas

A pesar de la refactorizacin de cdigo, es casi imposible que no hayan archivos generados a partir de los modelos que no deban ser completados por los desarrolladores. Para respetar los cambios realizados por los desarrolladores, en estos casos se utiliza el mecanismo de las Zonas Protegidas: bloques de cdigo delimitados por dos instrucciones, una de apertura y otra de cierre. Las lneas comprendidas entre ellas sern respetadas por el generador siempre. 1. Sintaxis Cada zona tiene el aspecto siguiente: /*PROTECTED REGION ID(preIniciarVentana__c7GjUIBSEeCc2cs1bFJTkw_PIU) ENABLED START*/ /* Escribe aqu el cdigo de la funcin */ /************************************************************/
/************************************************************/ /* Fin de la zona protegida */ /************************************************************/ /*PROTECTED REGION END*/ Las lneas con la palabra PROTECTED marcan el inicio y el final del bloque. La cadena que se encuentra encerrada entre los parntesis de ID es el identificador de la zona. Nunca se debe modificadar manualmente.
38
MOSKitt: Generacin de cdigo gvHidra 2. Activacin y desactivacin de las zonas protegidas La palabra ENABLED indica que la zona debe protegerse. Si se quita esa palabra, la zona se reescribir con lo generado. Por norma general, en una primera generacin las zonas en las que el generador haya necesitado incluir cdigo aparecern desactivadas y aquellas en las que no haya incluido nada estarn activadas. El desarrollador podr activar/desactivar las zonas protegidas a su conveniencia. 3. Identificadores de las zonas protegidas. Cada zona protegida estar etiquetada por un cdigo nico que la identifica. Este cdigo se contruye basndose en el identificador de los objetos que determinan su contenido. Estos identificadores no pueden ser modificados por los usuarios y el generador los mantiene de una generacin a otra. En la zona protegida que aparece en el punto ID(preIniciarVentana__c7GjUIBSEeCc2cs1bFJTkw_PIU). 1, el identificador es:
Si el usuario modifica el identificador de la zona protegida y el generador ya no la reconocer en futuras generaciones.
Cmo tengo que definir mis modelos para que los entienda el generador?
Este punto del manual est dirigido a aquellos analistas que estn modelando sus aplicaciones con la intencin de generar la mayor cantidad de cdigo gvHidra posible con MOSKitt. Con este objetivo vamos a describir cmo deben ser los modelos de entrada de la transformacin para obtener el mximo partido a la generacin de cdigo ya que hemos de ser conscientes de que el generador espera que los modelos de entrada estn definidos de una forma muy concreta.
Tareas 1 y 3: Los modelo UML2 y de Base de Datos.

El generador, en su versin 0.5.0 slo tiene en cuenta el Diagrama de Clases de un modelo UML2. De este diagrama hace uso de los siguientes elementos: Los tipos de datos de las propiedades de las clases para establecer los tipos gvHidra. Las asociaciones entre las clases para navegar en el modelo. Las enumeraciones para definir las listas estticas de valores. Necesita que el modelo de BD est trazado con el de UML2, es decir: 1. Que el modelo de BD se haya obtenido a partir de un modelo UML2 existente en el proyecto (para que exista la traza entre los dos). 2. Que el modelo de trazas (fichero .gvtrace) est tambin localizado en el proyecto. El generador navega al modelo de BD a travs del modelo de trazas y hace uso de prcticamente todos los elementos del modelo.
39
Tareas 6 y 9: Los modelos Sketcher y UIM

Conceptos Previos: Generacin de cdigo basada en Plantillas/ Patrones
El generador de cdigo de MOSKitt es un generador basado en plantillas, esto significa que si en los modelos de Sketcher/UIM hay definidas ventanas que no se basan en las plantillas que proporciona MOSKitt, estas ventanas no sern generadas. En este punto queremos remarcar una idea que ya ha aparecido en este manual: Qu ocurre cuando tengamos que especificar una ventana que no est an soportada por el framework o que su plantilla an no est disponible en el Sketcher?: En estos casos siempre podremos modelar la ventana usando todos los elementos que el Sketcher nos proporciona en su paleta, sin embargo, como no est basada en ninguna plantilla conocida por el generador, el cdigo no se incorporar a la aplicacin gvHidra. La idea es: "Siempre podremos modelar, aunque no podamos generar". Por lo tanto, en el caso de que un modelo contenga ventanas basadas en plantillas y otras que no lo estn, en la aplicacin gvHidra generada slo aparecern aquellas ventanas que s lo estn.
Cmo tengo que usar las plantillas/patrones proporcionadas por Sketcher/UIM

Como ya se ha comentado en secciones anteriores, las plantillas que proporciona MOSKitt se corresponden con los patrones de interfaz de usuario (pantallas y listados) definidos por la Gua de Estilo de la Consellera de Infraestructuras y Transporte. En estos patrones se establece una forma homognea de construir las interfaces de las aplicaciones de esta organizacin. Tienen adems la ventaja de que estn implementadas en el framework gvHidra. En resumen, los pasos a seguir para definir una nueva ventana seran: 1. Seleccionar el patrn que mejor se ajuste a las necesidades de la nueva ventana (para ms informacin ver secciones posteriores en este manual o el Manual de Usuario en la Ayuda de MOSKitt). Es necesario conocer bien el Catlogo de Patrones propuesto por la Gua de Estilo ya que se corre el riesgo de seleccionar un patrn incorrecto e intentar modificarlo hasta alcanzar el patrn deseado, con el agravante de que de este modo el resultado obtenido al generar el cdigo no ser el deseado. En caso de no encontrar ningn patrn que se ajuste a las necesidades del Analista se deber consultar con los responsables de definir la Gua de Estilo para determinar cual es la mejor solucin en cada caso y ver si se aaden patrones nuevos. 2. Cada patrn proporciona unas bases sobre las que se debe construir la ventana, pudiendo personalizarse mediante la creacin de nuevos elementos en l siempre y cuando sto sea compatible con la definicin de la plantilla.
Cmo se ha nombrado a cada una de las Plantillas?

Es importante conocer la Nomenclatura escogida para identificar a los patrones a la hora de seleccionarlos. Las plantillas que representan a los patrones de la Gua de Estilo estn definidos y nombrados en base a los siguientes criterios: Las operaciones bsicas que proporcionan: Consulta, Edicin e Insercin (C,E,I)4.
40
MOSKitt: Generacin de cdigo gvHidra El nmero de paneles que incluye el patrn: uno para todas las operaciones, uno para la consulta y otro para la insercin/edicin etc.... (1CEI, 1C1EI, etc...) El patrn de visualizacin que utilizan para mostrar los datos (Tabular o Registro).
As tendremos las siguientes plantillas de patrones simples: Plantilla Sketcher CIT Menu Principal Plantilla gvHidra Men Consulta Tabular Registro Tabular Edicin Tabular Registro Registro Tabular Registro Registro Registro Insercin
CIT 1CEI Tabular Tabular CIT 1CEI Registro Registro CIT 1C Tabular 1EI Registro CIT 1I Tabular - Registro Alta Masiva
En la siguiente figura vemos algunos ejemplos que aclaran la nomenclatura de las plantillas:
Las plantillas simples se pueden combinar para construir otras ms complejas, este es el caso de los patrones Maestro/Detalle: Plantilla Sketcher CIT MD Plantilla gvHidra Maestro Detalle Consulta Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular Edicin Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular Insercin Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular
41
MOSKitt: Generacin de cdigo gvHidra Plantilla Sketcher Plantilla gvHidra Consulta Detalle Tabular CIT MnD Maestro N Detalles Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular Detalle Tabular Edicin Detalle Registro Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular Detalle Registro Insercin Detalle Registro Maestro Tabular Maestro Registro Detalle Registro Detalle Tabular Detalle Registro
A continuacin tenemos una breve descripcin de cada uno de los patrones: CIT Men Principal: incluye una ventana para el patrn Men. CIT 1C 1EI TabularRegistro: incluye una ventana para el patrn 1C1EI con representacin en formato Tabular para la Consulta y en formato Registro para Edicin e Insercin. CIT 1CEI Registro: incluye una ventana para el patrn 1CEI con representacin en formato Registro para Consulta, Edicin e Insercin. CIT 1CEI Tabular: incluye una ventana para el patrn 1CEI con representacin en formato Tabular para Consulta, Edicin e Insercin. CIT Alta Masiva: incluye una ventana para el patrn 1I. Solamente implementa la parte de Insercin. CIT MD: incluye una ventana para el patrn MD. Por defecto, el Maestro sigue un patrn 1CEI Registro, y el Detalle un patrn 1C 1EI Tabular Registro. CIT Men Principal: incluye una ventana para el patrn Men. CIT MnD: incluye una ventana para el patrn MD, con n Detalles (por defecto 2). Por defecto, el Maestro sigue un patrn 1CEI Registro, y el Detalle un patrn 1C 1EI Tabular Registro (los 2). Para ms informacin sobre el comportamiento de los patrones de la Gua de Estilo consultar en la Ayuda de MOSKitt el "Uso de los patrones de la Gua de Estilo de la CIT con UIM" o el Manual de gvHidra.
Cmo reconoce el generador los elementos que contienen las plantillas?: Etiquetas
La pregunta que nos tenemos que hacer ahora es: Cmo reconoce el generador las plantillas?: Por su nombre? Porque comprueba su contenido y lo deduce? Por.....? El generador reconoce tanto las plantillas como los elementos que las componen gracias a un conjunto de etiquetas (tags) que funcionan a modo de palabras reservadas. Gracias a estos tags el generador asume ya una estructura y un comportamiento concreto en cada elemento, lo cual le permite tambin validar los modelos de entrada que recibe. Las etiquetas se pueden consultar en la pestaa de propiedades de cada elemento, subpestaa Tags.
42
Cada tipo de elemento tiene un conjunto de tags aplicable a l. A continuacin podemos ver algunos ejemplos de tags aplicables a elementos de tipo Window: Ventana_1CEI_Registro: etiqueta a la plantilla 1CEI_Registro. Ventana_1CEI_Tabular: etiqueta a la plantilla 1CEI_Tabular. Ventanta_1C_1EI: etiqueta a la plantilla 1C_1EI. Ventana_1I_AltaMasiva: etiqueta a la plantilla 1I_AltaMasiva. Ventana_MD: etiqueta a la plantilla MD. Ventana_MenuPrincipal: etiqueta a la plantilla MenuPrincipal. Ventana_MnD: etiqueta a la plantilla MnD. Las etiquetas aplicables a un elemento TabPanel seran: Rol_Maestro: etiqueta al panel que se corresponden con el maestro en una plantilla MaestroDetalle. Rol_Detalle: etiqueta al panel que se corresponden con el detalle en una plantilla MaestroDetalle. Rol_nDetalle: etiqueta a un panel que se corresponde con uno de los detalles de una plantilla Maestro-nDetalles. Las etiquetas aplicables a un elemento TabItem (una pestaa) seran: Modo_Busqueda: etiqueta a la pestaa donde se muestra la el filtro a aplicar en la bsqueda. Modo_Consulta: etiqueta a la pestaa donde se muestra el resultado de la bsqueda. Modo_ConsutlaEdicionInsercion: etiqueta a la pestaa donde adems de mostrar el resultado de una bsqueda se pueden ejecutar tambin las operaciones de edicin e insercin. Modo_EdicionInsercion: etiqueta a la pestaa donde se pueden ejecutar las operaciones de edicin e insercin. Modo_Insercion: etiqueta a la pestaa donde se ejecuta la operacin de insercin. Las etiquetas aplicables a un elemento Tree View Menu son: Menu_AModulosPrincipales: para modelar el submen de mdulos de la aplicacin.
43
MOSKitt: Generacin de cdigo gvHidra Menu_AAdministracionSistema: para modelar el submen de Administracin del Sistema. Menu_AHerramientasAuxiliares: para modelar el submen de Herramientas Auxiliares.
No vamos a entrar ahora a ver todas las etiquetas que hay definidas, para ello se puede consultar este manual en la seccin de anexos. Como podemos ver, todos los elementos que deben tener en cuenta el generador est etiquetados para relacionarlos con los elementos definidos por la Gua de Estilo, lo cual les dota de significado y hace que dejen de ser simples figuras en mi diagrama.
Importante: Para tener acceso a las Tags para gvHidra, es necesario iniciar el modelo del Sketcher con la template para gvHidra, o cargar el recurso que contiene las tags (platform:/plugin/es.cv.gvcase.mdt.sketcher.gvHidra/ models/sketcher_reusable_gvHidra.sketcher_diagram).
Conceptos Previos: Submodelo de Clases y Clase Principal

Toda ventana o panel lleva asociado un submodelo de clases formado por aquellas clases del modelo UML2 de las que se muestra alguna propiedad o se invoca algn mtodo en esta interfaz.
44
MOSKitt: Generacin de cdigo gvHidra Por ejemplo, supongamos el siguiente modelo clases para la aplicacin de facturacin:
Sin embargo, en el Mantenimiento de Clientes slo vamos a mostrar informacin de las clases que aparecen en la siguiente figura:
Este sera el submodelo de clases que interviene en la interfaz de Mantenimiento de Clientes. De todas las clases que pertenecen a cada uno de estos submodelos, siempre habr una que ser la que denominaremos Clase Principal, el resto de clases del modelo sern alcanzables desde sta y participan en la interfaz por estar relacionada con la clase principal. En ejemplo anterior, la Clase Principal es Cliente ya que en la ventana vamos a mostrar: De la clase Cliente las propiedades nif, nombre y apellidos. De la clase Cliente::Poblacion la propiedad nombre ( ojo! aqu estamos indicando: "el nombre de la poblacin del cliente" gracias a la navegacin). De la clase Clietne::Poblacion::Provincia la propiedad nombre ( ojo! aqu estamos indicando: "el nombre de la provincia de la poblacin del cliente" gracias a la navegacin). Es importante observar que NO hemos dicho lo siguiente:
45
MOSKitt: Generacin de cdigo gvHidra De la clase Cliente las propiedades nif, nombre y apellidos. De la clase Poblacion la propiedad nombre ( ojo! aqu estaramos indicando: "De todas las poblaciones, su nombre" por no indicar navegacin desde ninguna clase principal). De la clase Provincia la propiedad nombre ( ojo! aqu estaramos indicando: "De todas las provincias, su nombre" por no indicar navegacin desde ninguna clase principal). Donde indicamos la navegacin? Como ya hemos visto anteriormente al explicar cmo modelizar la interfaz de usuario con el Sketcher, esa es una propiedad asociada a cada uno de los widgets del modelo del sketcher ( propiedad Ruta Elemento Modelo).
Tarea 6: Modelo Sketcher

En este punto vamos identificar qu elementos del Sketcher son utilizados por el generador durante la generacin de cdigo y cmo. Lo iremos viendo aplicndolo a la aplicacin de facturacin.
Modelando el Men Principal de la aplicacin.

El generador tiene en cuenta los elementos: Menu Item Action y Menu Item Submenu (ambos entradas del elemento Tree View Menu utilizado para modelar el men de los mdulos de la aplicacin). Las propiedades que se deben tener en cuenta en estos elementos para generar cada entrada del men de la aplicacin son: Texto: El valor de esta propiedad ser el texto que aparecer en el submen de la aplicacin. Si el valor de esta propiedad es nulo, el generador usar el valor de la propiedad Id del men. Imagen: El texto ir acompaado por la imagen seleccionada en esta propiedad (el icono deber existir en la ruta igep/images/menu). Ventana Destino: Indica la navegacin de la entrada del men a una ventana concreta de la aplciacin. Desde la ventana de propiedades del widget se puede seleccionar una ventana ya existente cuando las haya (con el botn ...) o bien crearla directamente (con el botn +). Las Label que aparecen en la cabecera para poner el ttulo a la aplicacin en el men.5
Plantillas que entiende el generador.

Las plantillas que se generan con la versin 0.5.0 de MOSKitt codgen-gvHidra son: CIT Menu CIT 1CEI CIT 1C_1EI CIT 1I CIT MD - Maestro 1CEI / Detalle 1CEI (incluye MnD) CIT MD - Maestro 1CEI / Detalle 1C1EI (incluye MnD) CIT MD - Maestro 1CEI / Detalle 1I (incluye MnD)
46
Modelando los botones

Los botones que tiene en cuenta el generador son: Los IconButton localizados en el Panel Ttulo (tiene asociado el tag Panel_Titulo). Los Button localizados en el Panel Paginacin (tiene asociado el tag Panel_Paginacion).
Las propiedades que se deben tener en cuenta en estos elementos son: Texto: Si el botn lleva asociado un Tag el generador aplicar un texto fijo en funcin de ese tag. Si el botn no tienen ningn Tag asignado, el generador usar el texto que hayamos puesto en propiedad Texto del botn (Button). Los tags permitidos son: Accion_Buscar -> texto a mostrar Buscar. Accion_Guardar -> texto a mostrar Guardar. Accion_Cancelar -> texto a mostrar Cancelar.
47
MOSKitt: Generacin de cdigo gvHidra Imagen: Icono que se muetra en el btn (el icono deber existir en la ruta igep/images/ menu). Ventana Destino: Indica la navegacin de la entrada del men a una ventana concreta de la aplciacin. Desde la ventana de propiedades del widget se puede seleccionar una ventana ya existente cuando las haya (con el botn ...) o bien crearla directamente (con el botn +).
Modelando las ventanas

Los elementos del Sketcher que tiene en cuenta el generador codgen-gvHidra v.0.5.06 en la generacin de cdigo son: Grupo Basic: Textbox,CheckBox,ListBox,ComboBox y RadioButton y GroupBox (para agrupar elementos). Grupo DateTime: DateField,TimeField y Calendar. Grupo Table: Table, Table Row y Table Column. Adems el generador slo los tendr en cuenta si estos widgets estn localizados en uno de los siguientes paneles: Panel Modo_Consulta. Panel Modo_Busqueda.
6
En futuras versiones del generador pueden incorporarse ms elementos a la lista.
48
MOSKitt: Generacin de cdigo gvHidra Panel Modo_ConsultaEdicionInsercion. Panel Modo_EdicionInsercion. Panel Modo_Insercion. Para cada elemento, el generador tiene en cuenta las siguientes propiedades: Id: Identificador del widget (normalmente por claridad se indica el nombre de la propiedad de UML2 con la que se relaciona). Elemento Modelo: muestra con qu elemento del modelo de UML2 se relaciona el widget. Ruta Elemento Modelo: indica cmo se debe navegar en el modelo UML2 para alcanzar la informacin a mostrarl. Vamos a ver su utilidad con un ejemplo: Si selecciono la propiedad nif de la clase Cliente estaremos indicando que en la interfaz se van a mostrar todos los clientes y, para cada uno de ellos su nif. Sin embargo, si selecciono la misma propiedad, pero navegando desde la clase factura (a travs de la asociacin que tengo definida), estar indicando que lo que voy a mostrar es slo el nif del cliente de la factura. El generador tiene en cuenta esta informacin para establcer los Matchings, las tablas con las que se trabaja en una ventana, para generar las select y para obtener los campos que forman parte de las claves primarias y ajenas. Valor por defecto: cuando se entra en modo nuevo al panel aparece ese valor por defecto. Editable Obligatorio Visible Seleccionado (en CheckBox y RadioButton) Para las tablas, el tipo de visualizacion ser el del elemento que pongamos dentro de la celda de la tabla (Textbox,CheckBox,ListBox,ComboBox,RadioButton,DateField,TimeField,Calendar), si no existe se mostrara como un Textbox. Ejemplo: Vamos a ver un ejemplo de un Maestro-Detalle, donde tenemos: Un Filtro de Bsqueda (panel FIL en gvhidra). Un panel para el Maestro: formado por un nico panel Registro para mantener la Consulta, la Edicin y la Insercin ( panel EDI en gvhidra). Un panel para el Detalle: formado por un panel Tabular para la mantener la Consulta y otro panel Registro para mantener la Edicin e Insercin (paneles LIS y EDI respectivamente en gvhidra). Modelamos el Filtro (Panel de Bsqueda): En la siguiente figura podemos ver vemos el Panel Bsqueda (FIL), formado por dos TextBox, un Button para lanzar la bsqueda (Buscar) y un IconButton para Recargar la pgina:
49
Ya en ejecucin obtendramos lo siguiente como resultado de la generacin:
Modelamos ahora el Maestro /Detalle: Aqu podemos ver: 1. Panel Registro para Maestro (EDI), formado por 4 TextBox, 1 GroupBox, 2 Buttons y 3 IconButton. 2. Panel Tabular (LIS) para el Detalle, formado por una tabla con 3 columnas y 3 IconButton. En la tabla, en la primera y la segunda columna no se detalla su forma de visualizacin, pero en la tercera se indica que se va a visualizar como CheckBox.
50
MOSKitt: Generacin de cdigo gvHidra Ya en ejecucin obtendramos lo siguiente como resultado de la generacin:
Tarea 9: Modelo UIM

El modelo de UIM tambin tiene que cumplir una serie de propiedades para poder ser transformado a gvHidra. Como el modelo UIM que se genera a partir de la transformacin Sketcher2UIM ya cumple con todas estas propiedades y por el momento, la versin 0.5.0 del generador codgen-gvHidra no hace uso de ningn elemento de UIM que no provenga de esta transformacin no vamos a entrar en este punto. Para ms informacin consultar el Manual de Usuario de la transformacin Sketcher2UIM en la Ayuda de MOSKitt.
Versin 0.5.0: Casos a tener en cuenta en la generacin

Ya hemos explicado qu es el Submodelo de clases asociado a una interfaz de usuario (ventana o panel) y qu es la Clase Principal. En base a estos dos conceptos, vamos a identificar en qu casos la query que se genera en la Clase Manejadora tendr que ser reajustada por los desarrolladores en la versin 0.5.0 de codgen-gvHidra. Importante: En estos casos se generar cdigo pero la query de la clase manejadora tendr que ser revisada. Segn el caso, el ajuste que deber hacer el desarrollador ser mayor o menor. CASO1: Cuando se crea un widget en el Sketcher, se debe indicar la propiedad del UML2 con la que se relaciona. Si algn widget del sketcher no est relacionado con ninguna propiedad de UML2, la query generada tendr que ser ajustada por el desarrollador ya que, aunque incluye el widget en la plantilla, en la query no aparece. Si el widget debe mostrar una propiedad de alguna clase, es un error del anlisis. CASO2: Todas las propiedades de UML2 con las que se relacionan los widgets del Sketcher tienen que ser alcanzables desde la clase principal del panel. Vamos a tomar como ejemplo el siguiente diagrama de clases:
51
Por ejemplo, si en el panel consulta de una ventana de Mantenimiento de Clientes quisisemos ver, para cada cliente, su propiedades nif, nombre y apellidos y adems el nombre de la poblacin en la que vive deberamos definir en el Sketcher los siguientes widgets: Un Texbox para el nif enlazado con la propiedad nif de la clase Cliente del siguiente modo: Elemento Modelo=Cliente::nif (<Class>Cliente::<Property>nif) Ruta Elemento Modelo=Cliente::nif (<Class>Cliente::<Property>nif) Un Texbox para el nombre enlazado con la propiedad nombre de la clase Cliente del siguiente modo: Elemento Modelo=Cliente::nombre (<Class>Cliente::<Property>nombre) Ruta Elemento (<Class>Cliente::<Property>nombre) Modelo=Cliente::nombre
Un Texbox para los apellidos con la apellidos nombre de la clase Cliente del siguiente modo: Elemento (<Class>Cliente::<Property>apellidos) Ruta Elemento (<Class>Cliente::<Property>apellidos) Modelo=Cliente::apellidos
Modelo=Cliente::apellidos
Un Texbox para el nombre de la clase Poblacion enlazado del siguiente modo: Elemento (<Class>Poblacion::<Property>nombre) Modelo=Poblacion::nombre
Ruta Elemento Modelo=Cliente::Poblacion::nombre (<Class> Cliente :: <Association> Cliente_Poblacion :: <Class> Poblacion :: <Property> nombre). Pero, si hubiesemos definido el nombre de la Poblacion del siguiente modo: Un Texbox para el nombre de la clase Poblacion enlazado del siguiente modo: Elemento (<Class>Poblacion::<Property>nombre) Modelo=Poblacion::nombre
Ruta Elemento Modelo=Poblacion::nombre (<Class> <Property> nombre). Si se quiere mostrar la provincia del cliente es un error de anlisis.
Poblacion
::
Pero si lo que se quiere es mostrar el nombre de todas las provincia (lo cual no parece muy lgico por otro lado) deber ser el desarrollador el que ajuste la ventana. 52
MOSKitt: Generacin de cdigo gvHidra CASO3: Si entre dos clases hay una relacin 1:M (0:1----0:*, 0:1----1:* ect....), y queremos que en la ventana sea posible aplicar las operaciones de borrado/edicin/insercin a las instancias de ambas clases, se debe seleccionar un patrn Maestro-Detalle. Si no es as, el cdigo generado slo permitir establecer las referencias entre una instancia de la clase principal y una de las instancias de la clase secundaria y el desarrollador deber modificar el cdigo para que se comporte de la forma deseada. Por ejemplo: vamos a tener en cuenta las siguientes clases:
Si definimos una ventana maestro detalle (segn la plantilla CIT MD) con, por ejemplo, Factura en el Maestro y Linea de Factura en el Detalle, se generar una ventana en la que podremos dar de alta facturas y lineas en la factura, pero no podremos asociar lneas de factura ya existentes a una factura (esto no tendra mucho sentido en esta ventana pero en otros casos podra interesar hacerlo). En el panel del Maestro en el Sketcher definiremos las propiedades: Factura::numero Factura::fecha Y en el panel del Detalle en el Sketcher definieremos las propiedades: Linea de factura::numero Linea de factura::unidades El generador asume que la nica asociacin existente es la que las relaciona (ver restriccin relativa al CASO6 tambin aplicable en este caso). CASO4: En la versin 0.5.0 del generador, si entre dos clases hay una asociacin con cardinalidad M:M (1:*----1:*, *:*----1:* etc...) la ventana que se genera debe ser revisada por el desarrollador tanto para la consulta como para la edicin/insercin y borrado. Estaramos hablando de un caso como este:
Si definimos una ventana maestro detalle (segn la plantilla CIT MD) con, por ejemplo, Categoria en el Maestro y Producto en el Detalle, se generar una ventana con los widgets correspondientes pero el desarrollador deber reprogramar las operaciones de consulta, edicin, insercin y borrado. CASO5: En una jerarqua de herencia, si desde el sketcher se hace referencia a propiedades heredadas, segn cmo se haya hecho la transformacin a Base de Datos es posible que el desarrollador tenga que ajustar la query. Vamos a tomar como ejemplo la jerarqua de herencia que aparece en la siguiente figura:
53
Si en la ventana de Mantenimiento propiedades: Cliente::nif Cliente::nombre Cliente::apellidos
de
Clientes decidimos mostrar las siguientes
El generador construir correctamente la query asociada al panel. Pero, si adems incluimos la siguiente propiedad: Cliente::sexo Por ser sexo una propiedad heredada para el Cliente, es posible que el desarrollador tenga que revisar la query construida por el generador (la pista ser que no funciona la ventana). Vamos a intentar explicar ahora en qu casos funcionar y en qu casos no. Las tres posibilidades que tenemos al transformar la herencia a tablas son:
La query que nos construir el generador es la siguiente:
54
MOSKitt: Generacin de cdigo gvHidra $select = 'SELECT Cliente.nif AS "lisnif_Cliente", Cliente.nombre AS "lisnombre_Cliente", Cliente.apellidos AS "lisapellidos_Cliente", Cliente.sexo AS "lissexo_Cliente" FROM Cliente'; Por tanto, slo en el caso de haber adoptado la estrategia Only Child Table estara correcta la query en el caso de incluir la propiedad Sexo en la query. Esto es debido a que el generador en su versin 0.5.0 an no recorre todas las opciones en las que puede ser transformada una jerarqua de herencia, en prximas versiones se incluir esta mejora. Mientras, el desarrollador tendr que ajustar la query a la Base de Datos incluyendo un join cuando sea necesario. Sin embargo: 1. No crea el tipo de datos para la propiedad Sexo en l a clase manejadora SKU. 2. En la plantilla, el nombre de la variable sexo siempre se forma usando el nombre de la clase padre (lissexo_persona), por lo que no coincidir con el nombre que se ha incluido en la select para la misma variable (lissexo_cliente). {CWCheckBox nombre="lisSexo_Persona" oculto="false" textoAsociado="sexo" mostrarTextoAsociado="true" $dataType_CIT1CEIRegistro.lisSexo_Persona $defaultData_CIT1CEIRegistro.lisSexo_Persona } editable="true" dataType= value=
Por lo que el desarrollador deber revisar estos tres puntos para ajustar los nombres de las variables (clase manejadora, clase manejadora SKIU y tpl). CASO6: Las clases deben slo deben estar relacionadadas por una nica asociacin. Por ejemplo, en el caso que aparece a continuacin en la figura, los desarrolladores tendran que ajustar la query: En el diagrama de clases de la figura:
Supongamos una ventana en la que definimos que queremos visualizar las siguiente propiedades del cliente: Cliente::nif Cliente::nombre Cliente::apellidos Cliente::Poblacion::nombre (navegando a la clase Poblacion a traves de la asociacin Cliente_Poblacion) Cliente::Poblacion::nombre (navegando a la clase Poblacion a travs de la asociacin Cliente_LugarNac)
55
MOSKitt: Generacin de cdigo gvHidra La query que se obtiene como resultado no es la correcta, ya que: slo tiene en cuenta una de las propiedades Cliente::Poblacion::Nombre y hay que incluir la que falte. En la clausula Select slo tiene en cuenta uno de los dos campos En la clusula Where incluye dos JOIN con la misma tabla. Vamos a ver un ejemplo de la query que se generara: SELECT Cliente.nif AS "lisnif_Cliente", Cliente.nombre AS "lisnombre_Cliente", Cliente.direccion AS "lisdireccion_Cliente", poblacion.codigo AS "lisncodigo_poblacion", poblacion.nombre AS "lisNombre_poblacion" FROM fact.Cliente LEFT JOIN fact.poblacion ON fact.Cliente.poblacion_codigo1=fact.poblacion.codigo AND fact.Cliente.poblacion_provincia_codigo2=fact.poblacion.provincia_codigo LEFT JOIN fact.poblacion ON fact.Cliente.poblacion_codigo=fact.poblacion.codigo AND fact.Cliente.poblacion_provincia_codigo=fact.poblacion.provincia_codigo CASO7: Si se define una ventana que no se ajuste a ninguna plantilla, no se generar ningn cdigo asociado (en especial se puede echar de menos la plantilla correspondiente a la Ventana de Seleccin, la cual estar disponible a partir de la versin 0.7.0 del generador). CASO8: En las ventana Maestro-Detalle la relacin entre ambos el maestro y el detalle se obtiene directamente de la asociacin que exista entre las clases principales de ambos. En el caso de que no exista una asociacin directa en el modelo de clases, el desarrollador tendr que ajustar la query: Vamos a verlo de nuevo con un ejemplo basado en el diagrama de clases de la siguiente figura:
En este diagrama podemos ver que entre Cliente y Producto no hay ninguna asociacin directa. Pues bien, si el analista quisiese modelar una ventana Maestro-Detalle para mostrar los productos que le han sido facturados a un cliente, el generador, en su versin 0.5.0 no calcula la query completa y la tendr que ajustar el desarrollador.
56
MOSKitt: Generacin de cdigo gvHidra CASO9: Igual que ocurre en el interior de un panel, en una ventana Maestro-Detalle las clases principales del maestro y del detalle estn sujetas a al escenario descrito en el CASO5 (slo una asociacin entre clases). CASO10: Cuando en un maestro detalle las clases principales del Maestro y del Detalle estn relacionadas por una asociacin M:M, el desarrollador deber ajustar la query ya que no tiene en cuenta la tabla intermedia a la que esta asociacin da lugar en la Base de Datos. CASO11: Las listas desplegables que van asociadas a una propiedad UML2 de tipo enumeracin se generan correctamente, sin embargo, la transformacin no da soporte todava a las listas desplegables dinmicas. Si el tipo de datos es una instancia de otra clase, en lugar de una lista se crear un campo de texto. No hay soporte para dependencias entre listas.
En prximas versiones
En prximas versiones del generador se van a ir abordando todos y cada uno de los casos arriba descritos para que el desarrollador tenga que revisar los menos casos posibles. Para la versin 0.7.0 est previsto abordar los casos: CASO3: Asociaciones M:M entre las clases. CASO5: Propiedades heredadas. CASO7: Ventana de Seleccin. CASO10: Maestro detalle con asociaciones M:M entre las clases principales del maestro y del detalle.
Resolucin de errores comunes: Por qu no me ha generado esto o aquello?

Cmo resolver errores que ocurren al ejecutar la transformacin para generar el cdigo
Conflicto de Zonas Protegidas
Si hay un conflicto de Zonas Protegidas falla la ejecucin de la transformacin. Se produce esta situacin cuando, por algn motivo, hay dos ficheros en el proyecto que contienen dos zonas protegidas con el mismo ID y ambas estn activas.
57
MOSKitt: Generacin de cdigo gvHidra Para resolverlo seguir los siguientes pasos: 1. Limpiar las plantillas: Vaciar el contenido de la carpeta templates_c. 2. Comprobar los archivos. Si se ha modificado el modelo de forma que el nombre de los archivos ha cambiado, el antiguo sigue existiendo, y contiene los cambios. En este caso hay que hacer un merge manual en el cdigo y eliminar el antiguo. Los elementos que pueden provocar esta situacin son: Id de los enlaces a las ventanas en el men principal. Id de cada una de las ventanas Vamos a intentar explicar por qu se puede llegar a esta situacin: El ID de algunos elementos del Sketcher (enlaces de las ventanas del men principal y de las ventanas) se utiliza para dar nombre a los ficheros que crea el generador (clases manejadoras, includes etc....). El valor de esta propiedad es editable por el Analista. El ID de los elementos de los modelos se utiliza para identificar las zonas protegidas del cdigo al que dan lugar. Esta propiedad la maneja MOSKitt internamente y no es modificable por el Analista. Si se da el caso en el que un analista modifica la propiedad ID de una de las ventanas y vuelve a generar, tendremos otro fichero con un nombre diferente (el del nuevo ID) pero cuyo contenido es muy probable que sea casi el mismo y seguro que contiene zonas protegidas con el mismo ID. Ah tenemos un conficto de zonas protegidas.
Faltan ficheros en el proyecto

Hay que comprobar que en el proyecto estn todos los ficheros necesarios tal y como hemos explicado en la seccin 3 de este manual. Ante otros errores puede que la fuente provenga del intento de obtener el elemento correspondiente de la base de datos. 1. Comprobar en el modelo de configuracin, en el patrn Use Database que est seleccinado el modelo de base de datos correcto. 2. Comprobar que existen los modelos de trazas entre UML2 y DB y entre Sketcher y UIM.
Comprobar que la configuracin de la transformacin es correcta

El modelo de Base de Datos que hemos indicado en la configuracin de la transformacin debe ser el correcto y debe estar trazado con el modelo de UML2 correspondiente para evitar los errores a los que hace alusin el punto anterior (Faltan ficheros en el proyecto).
Cmo resolver errores ocurridos al ejecutar la aplicacin generada

Al ejecutar la aplicacin pueden darse errores aunque la generacin haya terminado correctamente. Aqu se muestran algunas recomendaciones: ERROR 1: Al acceder a la aplicacin el cuadro de login que aparece es el esttico por defecto y no el que hay en el custom. 1. Comprobar el archivo app/login.php. Este archivo debe apuntar al mtodo de autentifiacin del custom, si existe. 2. El custom est bien indicado en el archivo app/igep/gvHidraConfig.inc.xml.
58
MOSKitt: Generacin de cdigo gvHidra Entre las etiquetas <custom></custom> debe estar el custom deseado. 3. El custom existe. Dentro de la carpeta igep/custom existe una carpeta con el custom de la organizacin. ERROR 2: Tras hacer login en la aplicacin sale una pantalla en blanco 1. Revisar el archivo app/gvHidraConfig.inc.xml. El ttulo contiene los caracteres correctos Comprobar que el texto encerrado en las etiquetas <applicationName></ applicationName> no excede los 10 caracteres y no contiene acentos o caracteres especiales. Valores permitidos: [A-Z][a-z] Las conexiones definidas son vlidas En las zona <DSNZone> se especifican las conexiones a la base de datos. Si se ha definido una que no existe, modificarla/comentarla/eliminarla. 2. Existe la carpeta app/templates_c. Si no existe hay que crearla con permisos de escritura. ERROR 3: Al pulsar el enlace a una ventana no se abre. La aplicacin dispone de debug de gvHidra Abrir el debug de gvHidra y consultar los ltimos eventos registrados. 1. Error en la consulta SQL Implementar la consulta en la clase manejadora app/actions/Ruta_ventana/ ClaseManejadora.php. Es posible utilizar como base la que se encuentra en el constructor de app/actions/Ruta_ventana/skeleton/ ClaseManejadora_SK.php. 2. Error en los matchings. Revisar las funciones del archivo app/actions/Ruta_ventana/ ClaseManejadora.php. Las tablas que se utilizan para especificar los matchings de dameMatchingsPanel() deben aparecer entre las que se aaden en dameTablasPanel(). 3. No hay ningn error. Abrir el archivo app/include/menuModulos.xml y localizar la entrada de men. Comprobar que la opcin tiene un valor parecido al siguiente url="phrame.php? action=ClaseManejadora__iniciarVentana". 4. No hay ningn error y el panel est bien conectado al men. Repasar el cdigo de la clase manejadora por si hay algn error de sintaxis. El debug del framework no est configurado. Nota: Si se desea configurar el debug, los pasos necesarios se enumeran en el manual de usuario de gvHidra y quedan fuera del alcance de este documento. Repasar todos los apartados del punto anterior. 59
MOSKitt: Generacin de cdigo gvHidra ERROR 4: Al entrar en una ventana en modo consulta aparece un mensaje de error en la consulta sql y no aparecen datos. Implementar la consulta en la clase manejadora app/actions/Ruta_ventana/ ClaseManejadora.php. Es posible utilizar como base la que se encuentra en el constructor de app/actions/Ruta_ventana/skeleton/ClaseManejadora_SK.php. ERROR 5: Al pulsar el botn "Buscar" de una ventana en modo bsqueda aparece un mensaje de error en la consulta sql y no aparecen datos. Implementar la consulta en la clase manejadora app/actions/Ruta_ventana/ ClaseManejadora.php. Es posible utilizar como base la que se encuentra en el constructor de app/actions/Ruta_ventana/skeleton/ClaseManejadora_SK.php. ERROR 6: En una ventana Maestro-Detalle no se muestra el detalle correctamente. 1. Revisar el padre de la clase manejadora del panel maestro app/actions/Ruta_ventana/ skeleton/ClaseManejadora_SK.php y ver si tiene definida su relacin con el hijo. Si no la tiene, revisar la clase manejadora y aadirlo manualmente. 2. En caso de ser necesario, aadir los campos que hacen de enlace entre los paneles maestro y detalle a la select y a los matchings de la clase manejadora. ERROR 7: Que el panel encontrado no sea el esperado segn la estructura del patrn elegido. En este caso vemos como dentro de una ventana que en un principio iba a seguir el patrn CIT 1CEI_Registro, que contiene un TabItem con tag Modo_ConsultaEdicionInsercion, en lugar de contener el Panel_Registro esperado contiene un Panel_Busqueda. Para que este caso funcionara, se tendra que cambiar el tag del Panel_Busqueda por el Panel_Registro.
60
ERROR 8: La ventana no sigue ninguna plantilla conocida. En este caso vemos como la ventana no sigue ninguna plantilla conocida, no contiene nign Panel ni TabPanel ni TabItems, slo elementos widgets. Para que este caso funcionara, se tendra que elegir uno de los patrones detallados anteriormente.
ERROR 9: Que el panel contenga elementos no esperados para su rol.
61
MOSKitt: Generacin de cdigo gvHidra En este caso vemos como para una plantilla CIT MD, dentro del TabPanel etiquetado como Rol_Detalle, cuando encuentro un Panel_Registro, dentro me encuentro una Tabla en lugar de elementos simples. Para que este caso funcionara, se tendra que cambiar por Panel_Tabular o borrar la tabla y pegar elementos simples.
ERROR 10: Que el panel contenga paneles no esperados. En este caso vemos como un panel Registro contiene otro panel Registro. Para que este caso funcionara, se tendra que eliminar el segundo panel registro y copiar su contenido en el primero.
Anexos
Visin detallada de la estructura de las Plantillas en el Sketcher
En este apartado vamos a examinar con detalle los elementos que componen cada una de las plantillas. Es bastante especfico por lo que no se aconseja en una primera lectura del documento. Ms adelante, cuando ya se estn diseando interfaces con MOSKitt el usuario puede acudir a l y al Manual de Usuario del Sketcher que se encuenta en la Ayuda de MOSKitt para consultar detalles concretos de las plantillas.
62
MOSKitt: Generacin de cdigo gvHidra Men Principal Window con tag "Ventana_MenuPrincipal" TreeViewMenu con tag "Menu_AModulosPrincipales": dentro crearemos las diferentes entradas de men de nuestra aplicacin (MenuItemAction y SubMenu)
1I Alta Masiva Window con tag "Ventana_AltaMasiva" TabPanel TabPanelContenido sin tag. TabItem con tag "Modo_Insercion": usado para representar el panel de insercin. Panel con tag "Panel_Titulo" Panel con tag "Panel_Registro": donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
1CEI Tabular
63
MOSKitt: Generacin de cdigo gvHidra Window con tag "Ventana_1CEI_Tabular" TabPanel TabPanelContenido sin tag. TabItem con tag "Modo_Busqueda": usado para representar el panel de bsqueda. Panel con tag "Panel_Titulo" Panel con tag "Panel_Busqueda": donde crearemos los diferentes elementos (widgets) que componen nuestro filtro. TabItem con tag "Modo_ConsultaEdicionInsercion": usado para representar el panel de ConsultaEdicionInsercion. Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular": donde tendremos nuestra tabla. Dentro de cada celda, podemos definir (opcional) elementos (widgets) que serviran para definir el tipo de visualizacion de la tabla. Estos pueden ser Textbox,CheckBox,ListBox,ComboBox,RadioButton,DateField,TimeField,Calendar. Si no existe ninguna se mostrara como un Textbox.
1CEI Registro Window con tag "Ventana_1CEI_Registro" TabPanel TabPanelContenido sin tag. TabItem con tag "Modo_Busqueda": usado para representar el panel de bsqueda. Panel con tag "Panel_Titulo" Panel con tag "Panel_Busqueda": donde crearemos los diferentes elementos (widgets) que componen nuestro filtro. TabItem con tag "Modo_ConsultaEdicionInsercion"": usado para representar el panel de ConsultaEdicionInsercion. Panel con tag "Panel_Titulo"
64
MOSKitt: Generacin de cdigo gvHidra Panel con tag "Panel_Registro": donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
1C Tabular 1EI Registro Window con tag "Ventana_1C_1EI" TabPanel TabPanelContenido sin tag. TabItem con tag "Modo_Busqueda": usado para representar el panel de bsqueda. Panel con tag "Panel_Titulo" Panel con tag "Panel_Busqueda": donde crearemos los diferentes elementos (widgets) que componen nuestro filtro. TabItem con tag "Modo_Consulta"": usado para representar el panel de Consulta Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular": donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla). TabItem con tag "Modo_EdicionInsercion"": usado para representar el panel de EdicionInsercion. Panel con tag "Panel_Titulo" Panel con tag "Panel_Registro": donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
65
Maestro Detalle Window con tag "Ventana_MD" TabPanel TabPanelContenido con tag "Rol_Maestro". TabItem con tag "Modo_Busqueda": usado para representar el panel de bsqueda. Panel con tag "Panel_Titulo" Panel con tag "Panel_Busqueda": donde crearemos los diferentes elementos (widgets) que componen nuestro filtro. TabItem con tag "Modo_ConsultaEdicionInsercion": usado para representar el panel de Consulta Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular" donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla) o Panel con tag "Panel_Registro" donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla. TabPanel TabPanelContenido con tag "Rol_Detalle". CASO 1 TabItem con tag "Modo_ConsultaEdicionInsercion": usado para representar el panel de Consulta, Edicion, Insercin Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular" donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla) o Panel con tag "Panel_Registro" donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla. CASO 2 66
MOSKitt: Generacin de cdigo gvHidra TabItem con tag "Modo_Consulta"": usado para representar el panel de Consulta Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular": donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla). TabItem con tag "Modo_EdicionInsercion"": usado para representar el panel de EdicionInsercion. Panel con tag "Panel_Titulo" Panel con tag "Panel_Registro": donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
Maestro NDetalles Window con tag "Ventana_MnD" TabPanel TabPanelContenido con tag "Rol_Maestro". TabItem con tag "Modo_Busqueda": usado para representar el panel de bsqueda. Panel con tag "Panel_Titulo" Panel con tag "Panel_Busqueda": donde crearemos los diferentes elementos (widgets) que componen nuestro filtro. TabItem con tag "Modo_ConsultaEdicionInsercion": usado para representar el panel de Consulta Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular" donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla) o Panel con tag "Panel_Registro" donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
67
MOSKitt: Generacin de cdigo gvHidra TabPanel TabPanelContenido con tag "Rol_NDetalle" Para cada detalle encontrado existe: TabItem TabPanel con tag "Rol_Detalle", donde: CASO 1 TabItem con tag "Modo_ConsultaEdicionInsercion": usado para representar el panel de Consulta, Edicion, Insercin Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular" donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla) o Panel con tag "Panel_Registro" donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla. CASO 2 TabItem con tag "Modo_Consulta"": usado para representar el panel de Consulta Panel con tag "Panel_Titulo" Panel con tag "Panel_Tabular": donde tendremos nuestra tabla y posibles elementos dentro de las celdas (tipo de visualizacion de la tabla). TabItem con tag "Modo_EdicionInsercion"": usado para representar el panel de EdicionInsercion. Panel con tag "Panel_Titulo" Panel con tag "Panel_Registro": donde crearemos los diferentes elementos (widgets) que componen nuestra pantalla.
68
Lista completa de etiquetas que reconoce el generador.

En este apartado vamos a examinar con detalle los elementos que componen cada una de las plantillas. Es bastante especfico por lo que no se aconseja en una primera lectura del documento. Etiqueta Accion_Borrar Accion_BorrarValores Accion_Buscar Accion_Cancelar Accion_Editar Accion_Guardar Accion_Imprimir Accion_Insertar Accion_Interfaz Descripcin Accin para borrar el elemento actual. Accin para borrar los valores de un formulario. Accin para bsqueda. Accin para edicin. ejecutar cancelar una una Elementos en el Sketcher Button, IconButton Button, IconButton Button, IconButton Button, IconButton Button, IconButton Button, IconButton Button, IconButton Button, IconButton Button, IconButton, Calendar, CheckBox, ComboBox, DateField, ListBox, RadioButton, TextBox, TimeField Button, IconButton FeaturedLabel, Label FeaturedLabel, Label
Accin para editar el elemento actual. Accin para guardar o finalizar una transaccin. Accin para imprimir un listado. Accin para insertar un elemento nuevo. Accin para aadir operacin de Interfaz. una
Accion_Salto Fecha Usuario
Accin para navegar (saltar) de una ventana a otra. Indica que la informacin que se muestra es la fecha del sistema. Indica que la informacin que se muestra es el usuario que est conectado. Permite indicar el nombre de la aplicacin. Normalmente, se debe utilizar dentro del Patrn Men. Permite indicar el nombre de una ventana.
Nombre_Aplicacion
FeaturedLabel, Label
Nombre_Ventana
FeaturedLabel, Label BarMenu, PopupMenu, TreeViewMenu, ToolBarMenu BarMenu, PopupMenu, TreeViewMenu, ToolBarMenu
Menu_AAdministracionSistema Entrada del men principal Administracin del Sistema. Menu_AHerramientasAuxiliares Entrada del men principal Herramientas AuxiliaresAdministracin del Sistema.
69
MOSKitt: Generacin de cdigo gvHidra Etiqueta Menu_AModulosPrincipales Descripcin Entrada del men principal relativo a los Mdulos principales de la aplicacin. Representa el men de cualquier ventana de gvHidra. Identifica aquellos paneles que contienen el filtro de una ventana (el Modo Bsqueda de gvHidra). Identifica aquellos paneles que muestran el resultado de una consulta (el Modo Consulta de gvHidra). Elementos en el Sketcher BarMenu, PopupMenu, TreeViewMenu, ToolBarMenu BarMenu, PopupMenu, TreeViewMenu, ToolBarMenu Plantillas, TabItem
Menu_CIT
Modo_Busqueda
Modo_Consulta
Plantillas, TabItem
Modo_ConsultaEdicionInsercion Identifica aquellos paneles muestran el resultado de una consulta y adems permiten realizar las operaciones de insercin y edicin. Modo_EdicionInsercion Identifica aquellos paneles que permiten realizar las operaciones de insercin y edicin. Identifica aquellos paneles que permiten realizar la operacin de insercin. Indica que debe contener el Modo_Busqueda. Indica que debe contener el Nombre_Aplicacion. Indica que debe contener el elemento paginacin. Indica que el contenido muestra la informacin en formato registro. ndica que es el contenido del men superior de una aplicacin. Indica que el contenido muestra la informacin en formato registro. Indica que el contenido muestra la informacin en formato registro. Indica que contiene el ttulo de la ventana. Indica que el contenido describe 1 Detalle en un Maestro Detalle. Indica que el contenido describe 1 Maestroen un Maestro Detalle.
Plantillas, TabItem
Plantillas, TabItem
Modo_Insercion
Plantillas, TabItem
Panel_Busqueda Panel_NombreAplicacion Panel_Paginacion Panel_Registro
Panel Panel Panel Panel
Panel_Superior Panel_Registro
Panel Panel
Panel_Tabular
Panel
Panel_Titulo Rol_Detalle
Panel Panel,TabPanel
Rol_Maestro
Panel,TabPanel
70
MOSKitt: Generacin de cdigo gvHidra Etiqueta Rol_NDetalle Descripcin Indica que el contenido describe 1 Detalle en un Maestro Detalle. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn 1C1EI de UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn 1C1EI con Patrn de Visualizacin Registro en UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn 1C1EI con Patrn de Visualizacin Tabular en UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn 1I de UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn MD con 1 Detalle de UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn MD con N Detalle de UIM. Indica que el contenido que el contenido de la ventana es la plantilla se corresponde con el patrn Menu de UIM. Elementos en el Sketcher Panel,TabPanel
Ventana_1C_1EI
Window
Ventana_1CEI_Registro
Window
Ventana_1CEI_Tabular
Window
Ventana_AltaMasiva
Window
Ventana_MD
Window
Ventana_MnD
Window
Ventana_MenuPrincipal
Window
Importante: Para tener acceso a las Tags para gvHidra, es necesario iniciar el modelo del Sketcher con la template para gvHidra, o cargar el recurso que contiene las tags (platform:/plugin/es.cv.gvcase.mdt.sketcher.gvHidra/ models/sketcher_reusable_gvHidra.sketcher_diagram).
Descripcin detallada del cdigo gvHidra generado

Una vez se ha generado la aplicacin, es labor del desarrollador implementar manualmente los cambios y los mtodos que no se hayan creado automticamente. Para ello dispone de una serie de zonas protegidas (ver punto 5) en los ficheros que debe modificar. Ojo! Cualquier modificacin que se encuentre fuera de una de dichas zonas se perder si se vuelve a lanzar la transformacin.
Archivo de configuracin
Archivo app/gvHidraConfig.inc.xml. La transformacin permite crear dos conexiones de base de datos: la conexin principal y la conexin de debug. Si la aplicacin hace uso de ms conexiones hay que definirlas a mano. Por ello
71
MOSKitt: Generacin de cdigo gvHidra se ha creado una zona protegida en la que el programador pordr modificar los parmetros de las conexiones generadas automticamente y crear otras nuevas.
<DSNZone>   <dbDSN id='gvh_dsn_log' sgbd='postgres'> <dbHost>localhost</dbHost> <dbPort>5432</dbPort> <dbDatabase>gvhidra</dbDatabase> <dbUser>gvhidra</dbUser> <dbPassword>gvhidra</dbPassword> </dbDSN> <dbDSN id='g_dsn' sgbd='postgres'> <dbHost>localhost</dbHost> <dbPort>5432</dbPort> <dbDatabase>facturacion</dbDatabase> <dbUser>gvhidra</dbUser> <dbPassword>gvhidra</dbPassword> </dbDSN>   </DSNZone> Adems se define otra para el nombre y versin de la aplicacin. Si se quiere aadir algna etiqueta ms, hay que hacerlo ah.
Men de mdulos
Archivo app/include/menuModulos.xml. Dado que por el momento no est contemplada la generacin de cdigo en cuanto a usuarios y permisos, ni acciones personalizadas desde esas entradas, se proporcionan zonas protegidas en los tres archivos que contienen los mens. Cada entrada de men incluye su propia zona para poder modificarlas individualmente y que los archivos sean sensibles a nuevas incorporaciones.
  <modulo titulo="Gestin de productos" imagen="menu/43.gif" descripcion=""> <opcion titulo="Gestin de productos" descripcion="" url="phrame.php? action=MantenimientoProductos__iniciarVentana" imagen="menu/24.gif"/> 72
MOSKitt: Generacin de cdigo gvHidra </modulo> 
Includes
Archivo app/include/include.php. Existe una zona para que el desarrollador pueda cargar clases de forma manual.
Clase manejadora principal de la aplicacin

Archivo app/actions/principal/AppMainWindow.php. Contiene una zona protegida para que el desarrollador pueda implementar: Listas desplegables. Ventanas de seleccin.
Clases manejadoras
Contenidas en app/actions/*.De los tres archivos sobre los que se construye la clase manejadora, slo el que est fuera de la carpeta skeleton se debe modificar. En su interior hay definidas varias zonas protegidas, segn su cometido y ubicacin. Dentro del constructor. En esta zona se completa la definicin de la clase manejadora y se sobreescriben las propiedades completadas ya por el generador, en caso de ser necesario. Modificaciones en la SQL del panel. Modificacin de campos clave. Condiciones de bsqueda. Orden en que se muestran los resultados. Comportamiento del filtro. Comportamiento del panel tras la insercin. Definicin de nuevos tipos de datos. Relacin entre Maestro y Detalle (Si el panel es de dicho tipo) En la clase estn definidas todas las funciones pre/post que acepta el framework, con 0 como valor de retorno. En el interior de cada una hay una zona protegida en la que implementar su funcionalidad. La funcin accionesParticulares se define automticamente con las operaciones que se hayan detectado. Cada elemento case del switch se encapsula en una zona protegida. Se define una ltima zona con el default para que se implemente su funcionalidad. Si el programador tiene que aadir ms acciones al switch, lo debe hacer en este ltimo bloque. Hay un bloque con dos mtodos: dameTablasPanel y dameMatchingsPanel. En el primero se modifican las tablas involucradas en dicho panel, las que se deben pasar al constructor de la clase manejadora. En el segundo, se completan los matchings del panel si hay alguno que falta o no se ha creado correctamente. Al final del archivo se habilita una zona para que el programador escriba las funciones de negocio o de interfaz que queden fuera de la expresividad de los modelos.
73
Vistas
Archivos en app/views/*. Una por cada pantalla. Se crea una zona protegida para el paso de valores entre la clase manejadora y la plantilla o directamente para calcular un valor y pasarlo a smarty.
Plantillas
Archivos en app/plantillas/*. Normalmente hay una por cada pantalla. Las plantillas son archivos con muchas probabilidades de ser modificados. Adems dichos cambios pueden ocurrir prcticamente en cualquier lugar de su contenido. Una zona protegida por cada panel de la plantilla. De esta forma el desarrollador puede cambiar un slo panel y proteger slo esa zona.
Mappings
Los archivos de mappings se encuentran en app/include/mappings/*. Cada bloque de los mapping (dividiendo en bloques segn la accin y la clase manejadora) est limitado por una zona. As, es posible modificar cada uno de los mappings sin afectar al resto. Para cada panel se habilita una zona protegida con el fin de que el programador pueda insertar los mappings de acciones aadidas a mano.
74

Manual Codgen GvHidra 0.5.0

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Manual Codgen GvHidra 0.5.0

Diunggah oleh

Hak Cipta:

Format Tersedia

Captulo 1.

MOSKitt: Generacin de cdigo gvHidra

MOSKitt: Generacin de cdigo gvHidra

MOSKitt: Generacin de cdigo gvHidra

Descripcin de un caso de estudio: Desarrollo de una aplicacin de facturacin.

MOSKitt: Generacin de cdigo gvHidra

Tutorial: Proceso de desarrollo de aplicaciones con MOSKitt, pasos a seguir.

MOSKitt: Generacin de cdigo gvHidra

Tarea 1: Especificar la Lgica de Negocio: Modelo UML2

MOSKitt: Generacin de cdigo gvHidra Diagrama de clases (facturacion.uml_diagram).

Tarea 2: Obtener el modelo de Base de Datos: Transformacin UML2DB

Recursos de entrada de la tarea:

Tarea 3: Completar el Modelo de Base de Datos

Tarea 4: Generar los scripst DDL

Tarea 5: Generar la Base de Datos

Tarea 6: Especificar la Interfaz de Usuario: Crear el modelo de Sketcher

Tarea 6.1: Cmo crear un nuevo modelo de Sketcher.

MOSKitt: Generacin de cdigo gvHidra

Tarea 6.2: Como crear el Men Principal de la aplicacin

MOSKitt: Generacin de cdigo gvHidra

MOSKitt: Generacin de cdigo gvHidra

El contenido de la ventana depende de la plantilla seleccionada durante su creacin.

MOSKitt: Generacin de cdigo gvHidra

MOSKitt: Generacin de cdigo gvHidra

Tarea 6.5: Cmo completar la especificacin de la Interfaz de Usuario

MOSKitt: Generacin de cdigo gvHidra

Tarea 8: Obtener el modelo UIM: Transformacin Sketcher2UIM

Tarea 9: Completar el modelo UIM

Diferencias entre Sketcher y UIM

Tarea 10: Generar el cdigo gvHidra: Transformacin Sketcher2gvHidra

Ingeniera Inversa de la Base de Datos

MOSKitt: Generacin de cdigo gvHidra

Resultado de la generacin: Paseo por la aplicacin generada y su ejecucin

Al pulsar el botn Nuevo o Modificar se visualiza el panel de Edicin/Insercin de datos.

MOSKitt: Generacin de cdigo gvHidra

Resultado de la generacin: Paseo por los elementos ha creado el generador

Los archivos que se han generado: estticos y generados

Elementos generados por MOSKitt en estos archivos

MOSKitt: Generacin de cdigo gvHidra Plantillas. Mappings. Includes. Men principal.

Nombre que le da el generador a algunas variables que genera

Estrategia 1: Refactorizacin de cdigo

Refactorizacin de las clases Manejadoras: Herencia

Divisin de algunos ficheros por ventanas (Includes y Mappings)

MOSKitt: Generacin de cdigo gvHidra

Estrategia 2: Zonas protegidas

Si el usuario modifica el identificador de la zona protegida y el generador ya no la reconocer en futuras generaciones.

Tareas 1 y 3: Los modelo UML2 y de Base de Datos.

MOSKitt: Generacin de cdigo gvHidra

Tareas 6 y 9: Los modelos Sketcher y UIM

Cmo tengo que usar las plantillas/patrones proporcionadas por Sketcher/UIM

Cmo se ha nombrado a cada una de las Plantillas?

MOSKitt: Generacin de cdigo gvHidra

Conceptos Previos: Submodelo de Clases y Clase Principal

Tarea 6: Modelo Sketcher

Modelando el Men Principal de la aplicacin.

Plantillas que entiende el generador.

MOSKitt: Generacin de cdigo gvHidra

Modelando los botones

Modelando las ventanas

En futuras versiones del generador pueden incorporarse ms elementos a la lista.

MOSKitt: Generacin de cdigo gvHidra

Ya en ejecucin obtendramos lo siguiente como resultado de la generacin:

Tarea 9: Modelo UIM

Versin 0.5.0: Casos a tener en cuenta en la generacin