Repositorio Institucional de Documentos

ESCUELA DE INGENIERÍA Y ARQUITECTURA UNIVERSIDAD DE ZARAGOZA INGENIERÍA SUPERIOR EN INFORMÁTICA PLUGIN DE ECLIPSE PARA LA GENERACIÓN DE FORMULARIOS WEB PARA MC-SERVER v5.0 David Antón Lou 12 de febrero de 2013 ESCUELA DE INGENIERÍA Y ARQUITECTURA UNIVERSIDAD DE ZARAGOZA INGENIERÍA SUPERIOR EN INFORMÁTICA PLUGIN DE ECLIPSE PARA LA GENERACIÓN DE FORMULARIOS WEB PARA MC-SERVER v5.0 Empresa: TB-Solutions Advanced Technologies Director: Miguel Ángel Aranda Alcañiz Ponente: José Javier Merseguer Hernáiz Autor: David Antón Lou Zaragoza, 12 de febrero de 2013 Fdo: David Antón Lou Agradecimientos He de expresar todo mi agradecimiento a aquellas personas que me han ayudado, de una manera u otra, a llevar a cabo este proyecto, sin ellas no hubiese sido posible: A David Luna, mi codirector del proyecto, cuya importancia ha sido vital en el desarrollo del mismo. Me ha aportado muchos conocimientos de programación en Java, y me ha ayudado a adquirir experiencia en el campo de la banca electrónica. A Adrián García y Jorge Cholvis, por su atenta dedicación hacia mi y por sus aportaciones hacia este proyecto. Y para terminar, en el apartado personal, mi más sentida gratitud a mi familia por apoyarme en todo momento durante estos años tan duros, y a mis amigos por estar siempre a mi lado cuando más lo he necesitado. Resumen La utilización de formularios dentro de una página web resulta, actualmente, una tarea muy habitual dentro de las entidades del sector bancario, surgiendo la problemática de tener que estar en continuo contacto con programadores para la realización de pequeños cambios o creación de nuevas páginas. El objetivo que se persigue con el proyecto es el de construir una herramienta que permita la creación de formularios sin necesidad de tener altos conocimientos sobre lenguajes de programación. El presente proyecto, se va a encargar de realizar dicha tarea y para ello se ha pensado en una herramienta que funcione sobre una plataforma de software libre. Consistirá en un plugin para el entorno de programación Eclipse, y para facilitar su utilización por parte del usuario, se utilizará un entorno gráfico simple y amigable, haciendo uso de las librerías de edición gráfica(GEF), el sistema de modelado de eclipse(EMF) y del lenguaje de programación Java. El plugin de Eclipse, se subdividirá en dos partes claramente diferenciadas, que corresponden a las capas de controller y view del patrón de diseño MVC. El modelador, que corresponderá al controller y el diseñador al view. Serán dos zonas de edición gráfica diferentes, pero se interconectarán entre si para que se pueda completar toda la trazabilidad de la información. Las estructuras de datos con la información de los componentes gráficos se guardarán en ficheros, y existirá un fichero diferente para cada uno de los dos editores gráficos. El modelador se encargará de recibir operativas, hacer las operaciones necesarias sobre ellas, y proceder al envío de la información necesaria para la maquetación en la vista de la página web. Finalmente, en el diseñador se definirá el aspecto de la página o formulario para su posterior procesamiento y generación de código HTML. Esta herramienta, estará integrada dentro de la arquitectura MC-Server de la empresa TB- Solutions. MC-Server es un framework para implementación de aplicaciones web de misión crítica y transaccionales, que puede ser utilizado para dar servicio a distintas aplicaciones del sector de la banca electrónica. La motivación que me ha llevado a elegir este proyecto es poder realizar una herramienta que pueda ser utilizada por programadores con poca experiencia, para facilitar sus labores. Además, adquirir altos conocimientos en la programación en el lenguaje Java, así como, hacer hincapié en todas las fases de las que consta un proyecto de ingeniería del software de gran envergadura. 7 8 Índice general I Descripción del Proyecto 1 1. Introducción. Motivación y objetivos. 3 1.1. Motivaciones ................................... 4 1.2. Objetivos y Alcance del proyecto ......................... 4 1.3. Calendario del proyecto .............................. 4 2. Estado del arte. Antecedentes. 7 II Marco Teórico 9 3. Conceptos teóricos de MC-Server en banca electrónica. 11 3.1. Flujo de Entrada .................................. 11 3.2. Elementos de la Arquitectura ........................... 11 3.2.1. Micro Operative ............................. 12 3.2.2. Operative ................................. 12 3.2.3. Guided Operative ............................. 13 3.2.4. OutputFilter ................................ 13 3.2.5. Validation ................................. 13 3.2.6. Integration ................................ 14 3.2.7. PreExecution ............................... 15 3.2.8. AppData ................................. 15 3.2.9. ErrorCodes ................................ 16 3.2.10. BreadCrumb ............................... 16 3.2.11. BL Class ................................. 17 3.2.12. CB Class ................................. 18 3.3. Flujo de Salida .................................. 18 4. Tecnologías. 19 4.1. Lenguajes de programación ............................ 19 4.2. Entornos de programación ............................ 19 4.3. Librerías gráficas ................................. 20 4.4. Gestión del proyecto ............................... 20 I III Desarrollo e Implementación 21 5. Análisis del sistema. 23 5.1. Requisitos funcionales .............................. 23 5.2. Requisitos no funcionales ............................. 25 5.3. Interfaz de usuario ................................ 25 6. Diseño. 27 6.1. Casos de uso ................................... 27 6.2. Modelo de clases ................................. 29 6.2.1. Diagrama de clases del diseñador .................... 29 6.2.2. Diagrama de clases del modelador .................... 30 6.2.3. Diagrama de clases de las partes editables del diseñador ........ 31 6.2.4. Diagrama de clases de las partes editables del modelador ........ 32 6.2.5. Diagrama de clases de la vista del diseñador ............... 33 6.2.6. Diagrama de clases de la vista del modelador .............. 34 6.3. Diseño Visual ................................... 35 7. Implementación y pruebas. 37 7.1. Implementación .................................. 37 7.1.1. MC-EclipsePlugin ............................ 38 7.1.2. MC-EclipsePlugin.edit .......................... 41 7.1.3. MC-EclipsePlugin.editor ......................... 41 7.1.4. MC-EclipsePlugin.feature ........................ 45 7.1.5. MC-EclipsePlugin.tests .......................... 46 7.1.6. MC-EclipseUpdateSite .......................... 46 7.2. Pruebas ...................................... 48 7.3. Aspecto final del plugin .............................. 50 8. Conclusiones. Futuras líneas de trabajo. 55 IV Referencias y Bibliografía 57 Bibliografia 59 V Apéndices 61 II 6. Elaboración de la memoria y de los manuales del proyecto. (100 h.) El tiempo total de realización del proyecto se estima en unas 835 horas, que se repartieron en jornadas de 7 horas al día. A continuación se muestra una tabla con las tareas que se realizaron. Figura 1.1: Diagrama de Gantt - Tareas del proyecto El diagrama de Gantt (Figura 1.2) muestra el desarrollo total del proyecto, indicando las principales tareas. Figura 1.2: Diagrama de Gantt - Calendario del proyecto 5 6 Capítulo 2 Estado del arte. Antecedentes. MC-Server es la plataforma multicanal que permite a las entidades financieras desarrollar sus aplicaciones de banca online y poner a disposición de sus clientes cualquier operativa de Banca Electrónica, desde cualquier lugar, durante las 24 horas del día y en cualquier dispositivo(Internet, dispositivos móviles, iPhone, etc.). TB-Solutions, ofrece este producto, que garantiza el correcto funcionamiento de las aplicaciones bancarias sea cual sea el número de usuarios conectados al servidor, al mismo tiempo que le proporciona asistencia técnica ante cualquier incidencia. En la actualidad, más de 20 Entidades financieras confían en MC Server para sus aplicaciones de banca electrónica, por lo que es necesario desarrollar extensiones de este producto para hacerlo más completo. Una de las mejoras que se pensó realizar fue una aplicación de autogeneración de código para la plataforma MC-Server. Esta aplicación permitiría generar código HTML para formularios web, clases Java de tipo EJB(Enterprise Java Bean), clases Java para conexión con Web Services o con Host, así como clases Java específicas de la plataforma MC-Server. A continuación se muestran algunos ejemplos de aplicaciones ya desarrolladas que están relacionadas con la generación de código y podrían resultar complementarias a nuestro proyecto. 1. Mirabyte Web Architect -http://www.mirabyte.com/: Es una aplicación que se utiliza para la creación de páginas web profesionales. Soporta lenguajes como HTML, XHTML, CSS, JavaScript o PHP. Posee una interfaz de usuario muy intuitiva que hace que sea muy fácil familiarizarse con la aplicación. También cuenta con una gran cantidad de utilidades para conseguir que la edición de documentos web sea una tarea fácil y rápida. Por ejemplo, posee la característica de completado de código que ahorra mucho trabajo manual y agiliza tareas relacionadas con el desarrollo web. Además permite la creación de páginas web de manera gráfica facilitando así a los usuarios con pocos conocimientos de programación, generándoles automáticamente el código web. 2. Lombok Feature -http://projectlombok.org/features/index.html: Plugin para Eclipse de generación de código Java. Posee un conjunto de sentencias que 7 comienzan por el carácter ‘@’ y que posteriormente, Eclipse las tratará y realizará las acciones necesarias para cada una de las sentencias. 3. Microsoft FrontPage -http://office.microsoft.com/es-es/frontpage-help/: Es un editor de páginas web creado por la compañía Microsoft. Al igual que Mirabyte, se encarga de la generación de código web, en este caso HTML. Es muy sencillo de utilizar y permite al usuario generar páginas web de manera gráfica. El único inconveniente que posee, es que genera un código poco optimizado. 8 Parte II Marco Teórico 9 Capítulo 3 Conceptos teóricos de MC-Server en banca electrónica. TB-Solutions ha realizado numerosos proyectos Web en Java dedicados tanto a banca electrónica como a otros tipos de aplicaciones online. En cada uno de estos desarrollos se han utilizado distintas arquitecturas, aunque siempre basadas en el estándar J2EE. En este capítulo, se va a intentar explicar el modelo de una nueva arquitectura de trabajo para construir aplicaciones sobre banca electrónica. Esta arquitectura, bautizada como MC- Server, intenta definir los componentes a utilizar en el desarrollo de aplicaciones. Mediante esta arquitectura y el uso de una metodología claramente definida, se pretende que cualquier técnico de un departamento de desarrollo pueda entrar en la realización de este tipo de proyectos en el menor tiempo posible, incluso sin tener altos conocimientos previos de Java. En los siguientes apartados, se detalla en profundidad la arquitectura MC-Server, sobre la que se apoyará este proyecto. 3.1. Flujo de Entrada La entrada a la aplicación es siempre una petición http(request), y la respuesta será el resultado del proceso realizado en la aplicación y dependiendo del canal de salida, su formato será HTML, XML, WML, etc. 3.2. Elementos de la Arquitectura A continuación se explican brevemente los elementos que entran en juego en el proceso, su funcionalidad y su interrelación. No se entrará al detalle ni de programación, ni de tecnicis- 11 mos específicos. Se trata, en definitiva, de tener una visión global de la arquitectura MC-Server. 3.2.1. Micro Operative Las micro operativas son nodos con la marca o tag ‘micro-operative’, que identifican el nombre de la operativa y un atributo: name: Nombre de la micro operativa que deberá coincidir con el nombre de la vista(parámetro pageOperation del request). iden: False/true. Si necesita estar identificado para su ejecución. En las operativas marcadas como ‘micro-operative’, se pueden encontrar como nodos hijos de la misma, los tag obligatorios de ‘validation’, ‘error-codes’ y opcionalmente ‘integration’. 3.2.2. Operative Las operativas son nodos con la marca o tag ‘operative’, que identifican el nombre de la operativa y sus atributos, mas otro nodo hijo ‘CB-class’ con los atributos relativos a la clase y el método a invocar: name: Nombre de la operativa que deberá coincidir con el nombre de la vista(parámetro pageOperation del request). iden: False/true. Si necesita estar identificado para su ejecución. public: False/true. Nos dice si la operativa puede ser invocada desde el exterior. Por defecto todas son públicas. remoteAdress: Expresiones regulares opcionales separadas por comas que nos indican las IPs desde donde se permite la ejecución de las operativas. validationIPClass:Clase JavaBean externa para validación de IP. validationIPMethod: Método de la clase JavaBean que será ejecutado. Por defecto es el método del mismo nombre que la clase. Los argumentos que recibe son la IP de origen y las IP’s del ‘remoteAdress’ en caso de existir. class: Clase ControllerBean seleccionada para ejecutar. method: Método de la clase ControllerBean que será ejecutado. En las operativas marcadas como ‘operative’, se pueden encontrar como nodos hijos de la misma, los tag opcionales de ‘validation’, ‘integration’ y ‘app-data’. 12 3.2.3. Guided Operative Las operativas son nodos con la marca o tag ‘guided-operative’, que identifican el nombre de la operativa y sus atributos, mas otro nodo hijo ‘Guidance-class’ con los atributos relativos a la clase y el método a invocar: name: Nombre de la operativa que deberá coincidir con el nombre de la vista(parámetro pageOperation del request). iden: False/true. Si necesita estar identificado para su ejecución. public: false/true. Nos dice si la operativa guiada puede ser invocada desde el exterior. Por defecto todas son públicas. class: Clase GuidanceClass seleccionada para ejecutar. method: Método de la clase ControllerBean que será ejecutado. En las operativas marcadas como ‘guided-operative’, se pueden encontrar como nodos hijos de la misma, los tag opcionales de ‘validation’, ‘integration’, ‘app-data’, ‘breadcrumb’, ‘preExecution’, ‘outPutFilter’ y ‘view’. 3.2.4. OutputFilter Los filtros de salida son nodos con la marca o tag ‘OutPutFilter’, que identifican las verificaciones de una serie de parámetros. filterClass: Clase que contiene el código del filtro de salida. linkedToGuidedOperative: false/true. Nos dice si está asociado a una operativa guiada. param: Listado de parámetros que tendrá el filtro. 3.2.5. Validation La validación de cada operativa, marcada por ‘validation’, se compone por un atributo de este tag y de sucesivos hijos ‘parameter’ con los atributos relativos a la validación del parámetro. La lista de atributos de todos ellos es: class-infoset: Clase que implementa el info de paso de parámetros. name: Nombre del parámetro. Se admite el literal ‘*’ para validar cualquier parámetro desconocido. Añadiendo el literal ‘*’ al final del nombre del parámetro se valida éste como un plantilla, siendo el literal ‘*’ el sufijo del parámetro en la petición. format: Formato opcional de expresión regular que ha de tener el valor del parámetro. security-class: Clase opcional de seguridad externa para la validación del parámetro. 13 security-method: Método de la clase externa de seguridad a invocar. password: Marca que nos indica, de cara a su publicación en log, si es una contraseña o parámetro privado. Por omisión no está activo. optional: False/true. Nos indica que el parámetro es opcional. Su no presencia en la petición o su ausencia de valor es una validación correcta del mismo. compose-new: Nos indica si se trata de un nuevo parámetro a componer. El método de validación invocado no recibe parámetros. compose-from: Nos indica la lista de parámetros que componen un nuevo parámetro. Indicando plantillas, un nombre de un parámetro con sufijo ‘*’, en los parámetros del compose-from, se pueden hacer repeticiones de invocaciones al método con cada grupo de parámetros que cumplan la plantilla. El parámetro en el info de paso de parámetros ha de extender obligatoriamente de InfoSetAccesorPlus, y será en su ArrayList donde almacenemos los distintos resultados del método de composición. En los métodos de validación se permite el paso de literales a través del Controller marcándolos con ‘apóstrofes’. raise-error: Para parámetros compose-from y compose-new. En caso de fallar la validación compose levanta el error con nombre el valor de este campo. info-error: False/true. Marca si el parámetro ha de levantar un error en el info de paso de parámetros. Por defecto está a cierto. return: Nos indica la clase del objeto a guardar en el parámetro del info de paso de parámetros. paginated: Nos indica el número de páginas en que se troceará la respuesta. Página en cuanto al parámetro de page-param, los datos marcados por ‘paginated-infoSet’. page-param: Parámetro que nos indica la página solicitada de caché. paginated-infoSet: Nombre de las clases de los InfoSet a paginar separados por coma. alarm-class: Clase externa opcional para ejecutar una alarma en caso de que el parámetro no haya sido validado con éxito. alarm-method: Método a invocar de la clase externa de alarma. 3.2.6. Integration La integración está marcada por el tag ‘integration’ y tiene dos atributos relativos al nombre de la clase externa de integración y el método de invocación de la misma. El resto de la estructura del XML es libre, ya que será interpretado por la clase integradora. Sus atributos son: integration-class: Clase opcional de seguridad externa para la integración de la operativa. integration-method: Método a invocar de la clase externa de integración. 14 Parte III Desarrollo e Implementación 21 Capítulo 5 Análisis del sistema. En este capítulo nos centraremos en realizar la especificación de requisitos del sistema. Diferenciaremos entre requisitos funcionales, no funcionales y algunos aspectos sobre la interfaz de usuario. 5.1. Requisitos funcionales R.F. 1: Existirán dos editores gráficos: Controller Model Editor(modelador de operativas) y View Model Editor(diseñador de formularios). De esta manera se podrán editar las propiedades de los componentes de una manera más intuitiva. R.F. 2: El View Model Editor(diseñador de formularios) se encargará de crear la estructura visual del formulario web, previo a la generación del código HTML. R.F. 3: El Controller Model Editor(modelador de operativas) se encargará de tramitar las operativas de banca electrónica y generar vistas que sean necesarias. R.F. 4: El diseñador permitirá la creación de vistas asociadas a operativas. Cada operativa podrá tener como hijos un breadcrumb, un resource y/o un form. R.F. 5: El diseñador permitirá añadir componentes básicos al formulario, editar sus propiedades, cambiar su posición en pantalla y/o eliminarlos del editor. R.F. 6: Los componentes básicos con los que trabajará el diseñador de formularios serán: Label, TextBox, Password, Button, SubmitButton, ComboBox, RadioButton, CheckBox y FileComponent. R.F. 7: El diseñador permitirá añadir componentes avanzados al formulario, editar sus propiedades, cambiar su posición en pantalla y/o eliminarlos del editor. R.F. 8: Estos componentes avanzados serán: DateComponent, Conjuntos de botones y CCC. R.F. 9: El diseñador permitirá añadir eventos a los componentes del formulario. También dará la posibilidad de asociar una función javascript a los eventos. R.F. 10: El diseñador permitirá guardar la información en el fichero con extensión .view. 23 R.F. 11: El modelador permitirá la creación de operativas, micro operativas, operativas guiadas y filtros de salida asociados a un controller. R.F. 12: El modelador permitirá añadir nuevas micro operativas y/o editar sus propiedades. R.F. 13: Una micro operativa podrá tener una CB Class como objeto hijo. R.F. 14: Se permitirá la generación de clases CB(Controller Bean). Además se permitirán generar las clases resultado de tipo Info y el código de la validación relacionada. R.F. 15: El modelador permitirá añadir objetos a una operativa guiada, editar sus propiedades, cambiar su posición en pantalla y/o eliminarlos del editor. R.F. 16: Los objetos que se podrán añadir a la estructura de una operativa guiada serán: AppDataObject, GuidedOperativeObject, IntegrationDataObject, OutPutFilterObject, PreExecutionObject, ResultViewObject y ValidationObject. R.F. 17: El modelador permitirá crear conexiones de tipo OK, ERROR, OTHER, SinE- tiqueta o VALIDATION-ERROR entre GuidedOperative y ResultView. Y también permitirá crear conexiones SinEtiqueta desde un GuidedOperative hacia cualquier otro elemento. R.F. 18: Una operativa guiada podrá tener como objetos hijos: preExecutionObject[0..1], integrationObject[0..N], guidanceClass[0..1], outPutFilter[0..N], appDataObject[0..N], breadcrumb[0..1], validation[0..1] y resultViewObject[0..N]. R.F. 19: Una operativa guiada no podrá tener ningún resultView asociado si no posee un hijo de tipo guidanceClass. R.F. 20: Un resultView podrá tener una conexión directa con uno o varios guidedOperativeObject. R.F. 21: Al crear un resultView se podrá seleccionar el tipo de vista(PAGE, BINARY, STRING, XML, FILE o JSP) y el tipo de conexión. R.F. 22: El modelador permitirá guardar la información en el fichero con extensión .controller. Al proceder al guardado del controller, se guardarán en el fichero .view las vistas que no estuvieran ya creadas. R.F. 23: El sistema contendrá una opción para validar que los datos introducidos en el controller y en el view son correctos. R.F. 24: El sistema permitirá la conversión de los ficheros de la versión 4.0 de MC- Server a la versión 5.0 y viceversa. R.F. 25: El sistema permitirá la generación de clases BL( o Bussiness Logic ) para la conexión con Host, con una base de datos o con un servicio web. Además de crear la clase BL, se crearán las clases Info e InfoSet asociadas. R.F. 26: Las conexiones con Host será necesario que contengan una dirección URL y un puerto asociado. R.F. 27: Las conexiones con bases de datos permitirán seleccionar el driver a utilizar(DB2, MySQL, Oracle o SQL Server). 24 R.F. 28: Las conexiones con servicios web, permitirán seleccionar el fichero WSDL con el que trabajar mediante una dirección URL, seleccionando una ruta del sistema o un fichero por defecto. R.F. 29: El sistema permitirá la generación de ficheros EJB(Enterprise Java Bean) de tipo jar para la conexión con diferentes tipos de base de datos. R.F. 30: Los tipos de EJB que podrán generarse serán de la version 1.3, 2.0 y para el servidor de aplicaciones J2EE webLogic. 5.2. Requisitos no funcionales R.N.F. 1: La aplicación deberá de funcionar sobre la plataforma de desarrollo Eclipse 3.7 o superiores. R.N.F. 2: El java development kit(JDK) deberá de ser 1.6 o superior. R.N.F. 3: La aplicación será multiplataforma para poder ejecutarse en cualquier sistema operativo. R.N.F. 4: El sistema sobre el que se ejecute deberá de tener un mínimo de 1GB de memoria RAM. R.N.F. 5: Se informará por pantalla en caso de introducir algún dato erróneo en la aplicación. R.N.F. 6: En todo momento, el usuario estará informado sobre el lugar en el que se encuentra para facilitar su navegación por la aplicación. R.N.F. 7: Se podrá llegar a todas las opciones de la aplicación en 3 clics o menos. 5.3. Interfaz de usuario La usabilidad de la interfaz gráfica de usuario (GUI) es un aspecto muy importante en este proyecto, ya que va a ir destinado a usuarios con diversos tipos de conocimientos informáticos. Los editores contarán con paletas gráficas que facilitarán al usuario a la hora de añadir nuevos elementos. En el editor se mostrarán los elementos con sus propiedades de manera que el usuario se evite hacer demasiados clics. Todas las ventanas de la aplicación contendrán un título y una breve descripción para que el usuario sepa lo que está realizando en cada momento. Cada uno de los elementos tendrá un color representativo para facilitar la interpretación más intuitiva. 25 26 Capítulo 6 Diseño. En este capítulo se presentarán los detalles de diseño del proyecto, basándonos en el análisis del capítulo anterior. Se realizarán una serie de diagramas que ayudarán a la hora de realizar la implementación. 6.1. Casos de uso Se ha optado por utilizar notación UML para la realización del diagrama de casos de uso del sistema. Representa la funcionalidad más básica y general, y además, define todas las posibles interacciones del sistema con los usuarios. La imagen que mostramos a continuación detalla el diagrama de casos de uso utilizado por el plugin de MCServer y en el que se pueden diferenciar claramente los grandes bloques en los que se subdivide la aplicación. 27 Figura 6.1: Diagrama de casos de uso 28 6.2. Modelo de clases A la hora de realizar el diagrama de clases completo, se vio imposible condensar todo el sistema en un único diagrama, por lo que se decidio subdividirlo en varios submodelos. Además, se ha prescindido de representar todas las funciones de cada clase para obtener una mayor claridad y facilidad de comprensión. 6.2.1. Diagrama de clases del diseñador En el primer diagrama, figura 6.2 representa el modelo de clases del diseñador de formularios. Posee una clase base, AbstractEditableObject, de la que heredan las propiedades y métodos las demás clases. A parte, está la clase AbstractSubcomponent, de la que extienden todos los subcomponentes ya que poseen muchos atributos similares. Figura 6.2: Diagrama de clases del diseñador de formularios 29 6.2.2. Diagrama de clases del modelador El diagrama de la figura 6.3 representa el modelo de clases del modelador. Posee una clase base, AbstractConnectableObject, de la que heredan las propiedades y métodos las demás clases. Se caracteriza por tener una lista de conexiones de origen y de destino para interconectar diferentes objetos. A parte, está la clase AbstractEditableObject, de la que extienden todos los objetos que se encuentran internos en algún objeto AbstractConnectableObject. Figura 6.3: Diagrama de clases del modelador 30 Capítulo 7 Implementación y pruebas. Como ya se ha comentado en capítulos anteriores, la implementación del plugin para Eclipse será programada principalmente en Java, utilizando otros lenguajes auxiliares para su correcto funcionamiento. En este apartado, se describirá la estructura interna de la aplicación, así como los aspectos más destacables en la implementación de la misma y el plan de pruebas seguido para verificar su correcto funcionamiento. 7.1. Implementación El desarrollo del plugin de Eclipse se va a subdividir en varios proyectos que dependen unos de otros, pero así se consigue no sobrecargar toda la implementación en un único proyecto. De esta manera, la estructura general que se va a utilizar es la que aparece a continuación en la imágen y de la cual explicaremos cada proyecto con más detalle. Figura 7.1: Estructura de proyectos en Eclipse 37 7.1.1. MC-EclipsePlugin Es un proyecto de tipo ‘Java Project’, y es el encargado de almacenar los ficheros de configuración del modelo del plugin, y fue la primera de las tareas que hubo que realizar. Estos ficheros son de tipo Ecore(Eclipse Core) y permiten definir de manera arborescente cómo va a ser la estructura de los elementos. Esta estructura será utilizada por la librería EMF(Eclipse Modeling Framework) de Eclipse para la generación de código que pueda utilizarse para implementar el plugin. Además, tendremos otro tipo de ficheros GenModel, que se asociará al fichero Ecore correspondiente y que utilizaremos para la autogeneración de código del editor, del modelo y para las pruebas unitarias. A continuación mostramos una imagen con el menú desplegable de la generación de codigo a partir del fichero GenModel. Figura 7.2: Fichero GenModel 38 Para la autogeneración de código, habrá que editar una serie de propiedades en el fichero GenModel como mostramos a continuación. Figura 7.3: Propiedades del fichero GenModel En este proyecto, estará tambien el fichero plugin.xml. Podremos editar una serie de propiedades del mismo, dependencias entre los diferentes proyectos, y librerías, que nos servirán para la creación global de todo el plugin. Mostramos a continuación una imagen de la edición de este fichero. 39 Figura 7.4: Fichero plugin.xml 40 7.1.2. MC-EclipsePlugin.edit Es un proyecto de tipo ‘Java Project’, y es el encargado de almacenar los ficheros que se han autogenerado con el fichero GenModel explicado en el apartado anterior. Estas clases nos servirán para obtener las instancias a los objetos del modelo y para almacenar o modificar sus propiedades. Mostramos una imagen con la estructura de los paquetes generados en este proyecto. Figura 7.5: Fichero plugin.xml 7.1.3. MC-EclipsePlugin.editor Es un proyecto de tipo ‘Java Project’, y se podría decir que abarca el grueso de la implementación del plugin. Tendrá los paquetes referentes a la implementación de los dos editores gráficos(designer y modeler), otro paquete con las clases autogeneradas para mostrar la estructura arborescente de los ficheros(models) y otro paquete para acciones variadas del plugin(editor.actions). 41 Figura 7.6: Estructura del editor Explicaremos en más detalle a continuación los aspectos más importantes de la implementación del editor gráfico de la vista y del controlador. Para estos dos editores, existen clases similares, asi que nos centraremos en detallar la estructura general de la implementación independientemente de cual se trate. En el apartado anterior de diseño se puede apreciar con mayor detalle las principales diferencias en las clases de cada uno de los dos editores. a) Package com.tbsolutions.mcserver.eclipse.designer.model Contiene todas las clases base que utilizará el diseñador(las principales serán FormObject para el formulario, ComponentObject para todas las componentes, AbstractSubcomponent clase abstracta de la que extenderán los subcomponentes). Todas las clases base, extenderán de la clase abstracta AbstractEditableObject, la cual poseerá todas las propiedades comunes (literal, estilo, alineaciones, tamaños, elemento padre, lista de subelementos y el rectángulo gráfico). Además extenderá de la clase Observable para que puedan realizarse las notificaciones de cualquier cambio sobre un elemento y producirse su actualización en pantalla. La relación que existirá entre los elementos será la que se muestra en la imagen a continuación: 42 Figura 7.7: Relación entre elementos del diseñador Además, este package contiene un fichero componentes.xml desde el cual se crearán dinámicamente todos los componentes. De esta manera resulta muy cómodo realizar modificaciones sobre los elementos sin tener que hacer excesivos cambios. Se adjunta a continuación un fragmento de este fichero: Figura 7.8: Fragmento del fichero componentes.xml 43 b) Package com.tbsolutions.mcserver.eclipse.designer.view Contiene todas las clases necesarias para dibujar por pantalla todos los elementos. Estas clases extienden de AbstractControlFigure que a su vez extiende de RoundedRectangle y contiene las propiedades comunes de todos ellos. La función principal es la de paintFigure, que editará el rectángulo de cada elemento y lo posicionará en el gridData correspondiente. Por claridad a la hora de mostrar el formulario en pantalla se decidió que todos los elementos fueran rectángulos. c) Package com.tbsolutions.mcserver.eclipse.controller Contiene las clases necesarias para la creación de los editPart(objetos sobre los que está permitido realizar acciones) de las diferentes componentes. Todas las clases extienden de Observer y de NodeEditPart. La función createEditPolicies nos permitirá añadir las acciones que permitimos sobre ese objecto (edición, borrado, cambio de posición, cambio de tamaño, ). Mostramos a continuación un ejemplo de editParts: Figura 7.9: Ejemplo de EditPart d) Package com.tbsolutions.mcserver.eclipse.designer.wizard Contiene toda la definición de los wizard de creación/edición de elementos del formulario. Se pretende que se pueda configurar de manera sencilla todas las propiedades que tiene asociadas y poder observar el resultado al cerrar el wizard. Los datos introducidos se almacenarán en el fichero .view y se cargarán al abrirlo en el editor gráfico. e) Package com.tbsolutions.mcserver.eclipse.designer.command Contiene las clases de definición de los comandos de creación y/o edición para cada componente. Son las clases desde donde se invoca a los wizard. Las clases extienden a la clase Command yEditableCreateCommand, y cada elemento tiene asociado comandos propios de creación, ya que tienen que invocar a wizards diferentes y con propiedades diferentes. f) Package com.tbsolutions.mcserver.eclipse.designer.palette Contiene la clase OperativeGraphPalette que se encarga de definir la paleta gráfica con las componentes que se podrán insertar en el formulario. El aspecto final de la paleta es como el que mostramos a continuación: 44 Figura 7.10: Paleta gráfica del diseñador de formularios 7.1.4. MC-EclipsePlugin.feature Es un proyecto de tipo ‘Project’ y únicamente contendrá un fichero feature.xml donde se detallan las características de cada versión del plugin y que aparecerán cuando un usuario quiera descargarselo desde el servidor de actualizaciones de Eclipse. Desde este mismo fichero se podrán crear versiones para desplegar en el servidor(deployable features). Mostramos a continuación una imagen con las principales propiedades que se pueden editar del plugin. 45 Figura 7.11: Feature 7.1.5. MC-EclipsePlugin.tests El MC-EclipsePlugin.tests, es un proyecto de tipo ‘Java Project’ y se encargará de almacenar las clases Java que se utilizarán para la realización de los test unitarios. Para realizar la ejecución de los mismos, utilizaremos un complemento de Eclipse que se llama JUnit y que explicaremos con más detalle en la sección de pruebas. 7.1.6. MC-EclipseUpdateSite El MC-EclipseUpdateSite, es un proyecto de tipo ‘Update Site Project’ y su principal funcionalidad es la de establecer la estructura necesaria para la plataforma de publicación de plugins Eclipse Update Manager. De esta manera, mediante una url se podrá descargar y actualizar en cualquier momento el plugin. A este proyecto se le vincula el proyecto MC-EclipsePlugin.feature visto en apartados anteriores que tendrá el contenido a publicar. El fichero principal del proyecto es site.xml y nos permite definir las categorías a visualizar en el Eclipse Update Manager. En nuestro caso, únicamente hemos definido una sola categoría como mostramos en la figura. 46 A continuación, observamos un formulario con tres componentes y un menú desplegable con las opciones disponibles para ese objeto. El menú desplegable de edición para el modelador de operativas tendrá el mismo aspecto. Figura 7.19: Edición de componentes 53 Y finalmente, un ejemplo de wizard que permite la introducción de las propiedades asociadas al elemento seleccionado. Los wizards para el modelador de operativas tendrán el mismo aspecto. Figura 7.20: Aspecto final wizard 54 Capítulo 8 Conclusiones. Futuras líneas de trabajo. La plataforma Eclipse, se encuentra entre las más utilizadas actualmente por las empresas del sector del desarrollo software. Por ello, la realización de plugins para esta plataforma resultan de gran utilidad ya que pueden ser utilizados por multitud de usuarios, además de su cómoda y rápida distribución vía su repositorio de descarga de plugins. Por estos motivos, ha resultado de gran utilidad, tanto personalmente como por parte de la empresa, el trabajar con esta plataforma de software libre. La principal finalidad que se deseaba obtener con este proyecto era la de comenzar con su utilización de manera inmediata en la propia empresa para el desarrollo de nuevas aplicaciones de banca electrónica que utilizaran la plataforma MC-Server. En la actualidad, el plugin desarrollado en este proyecto, está siendo utilizado por programadores de la empresa TB-Solutions. Se decidió añadirlo en la etapa de implementación para el proyecto de desarrollo de la nueva banca electrónica para la entidad CAN(Caja Navarra). Las primeras impresiones que se obtienen son bastante positivas para ser una primera versión del plugin. Resulta de gran comodidad ya que en tareas muy sistemáticas se ahorra tiempo de producción, y además mayor comodidad a la hora de editar las propiedades de los ficheros propios de la plataforma MC-Server(ficheros .model, .controller y .view). Para futuras versiones, se tiene pensado en ampliar y/o mejorar alguna de las funcionalidades que ofrece esta primera versión del plugin, así como retomar otras que hayan quedado pendientes de implementación.. También se pretende reforzar el aspecto de las validaciones de datos que resulta imprescindible para el perfecto funcionamiento de la aplicación. Además, mediante su temprana implantación, se desea obtener cualquier tipo de fallo o carencia para poder mejorarla y que se encuentre perfectamente operativa para los usuarios. 55 56 Parte IV Referencias y Bibliografía 57 Bibliografía [1] Koen Aers. Developing an editor for direct graphs - gef introduction, 2008. http://www.inf.ed.ac.uk/teaching/courses/ip/resources/GEF/gef.eclipsecon.2008.pdf. [2] Frank Budinsky. Eclipse Modeling Framework. The Eclipse Series, 2003. [3] The Eclipse Foundation. Eclipse documentation, 2011. http://help.eclipse.org/indigo/index.jsp. [4] Bill Moore. Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework. RedBooks, 2004. [5] T.J. Watson. Eclipse 2.0 jdt plug-in developer guide, 2002. . 59 60 Parte V Apéndices 61 69 3.-Desinstalación del plugin En el momento que deseemos desinstalar el plugin, deberemos realizar unos sencillos pasos que explicamos a continuación. Accedemos a la pantalla de instalación de nuevo software, en el menú Help de Eclipse y hacemos click sobre el link alredy installed. 70 Se mostrará una pantalla como la de a continuación, donde seleccionaremos la entrada del MCServerPlugin y presionaremos sobre el botón Uninstall. 71 Se nos mostrará una pantalla intermedia con los detalles de la desinstalación. Para finalizar la desinstalación, presionaremos sobre el botón Finish. 72 Manual de Instalación 1.- Introducción En este manual se explicará cómo realizar cada una de las posibles funcionalidades que posee el plugin para MCServer. Para su utilización en un proyecto real, además, sería necesario añadir al proyecto la librería mcserver.jar para poder reconocer el contenido de los ficheros que generemos con el plugin. 2.- Creación de ficheros Con este plugin, podremos generar los cuatro ficheros principales que utiliza MC- Server. La estructura en un proyecto quedaría como se muestra a continuación. Para la generación de dichos ficheros, presionaremos sobre el proyecto y seleccionaremos la opción New y luego Other y se nos abrirá una pantalla como la siguiente. 73 A continuación, explicaremos como generar cada uno de los ficheros con sus propiedades correctas. 74 2.1.- Creación de ficheros .model Seleccionamos de la ventana de nuevo fichero, el de tipo Model y le damos un nombre como mostramos a continuación. Seguidamente deberemos de dar las propiedades a la estructura del fichero. Primero seleccionaremos el modelo del objeto, que siempre deberá de ser de tipo Model, como mostramos a continuación. 75 Por último, seleccionaremos el tipo de codificación XML que deseemos, en nuestro caso será la ISO-8859-15. Al presionar sobre el botón Finish tendremos correctamente creado el fichero de model. 76 2.2.- Creación de ficheros .controller Seleccionamos de la ventana de nuevo fichero, el de tipo Controller y le damos un nombre como mostramos a continuación. Seguidamente deberemos de dar las propiedades a la estructura del fichero. Primero seleccionaremos el modelo del objeto, que siempre deberá de ser de tipo Controller, como mostramos a continuación. 77 Por último, seleccionaremos el tipo de codificación XML que deseemos, en nuestro caso será la ISO-8859-15. Al presionar sobre el botón Finish tendremos correctamente creado el fichero de control. 78 3.- Model Una vez creado un fichero de tipo model, tendremos que poder configurarlo para su ejecución sobre la plataforma MCServer. 3.1.- Creación de una clase BL Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar operative. Editamos el nombre de la operativa mediante la pestaña de propiedades de la parte inferior de Eclipse. Finalmente, hacemos click con el botón derecho sobre la operativa, New Child y seleccionar BL Class. 3.2.- Generación de una clase BL Una vez creada la clase BL en el modelo, procederemos a la generación del código java. Se realizará des de la barra de herramientas, opción MCServer como se muestra en la imagen. 85 Una vez seleccionada la opción de Generar BL, se mostrará una pantalla como la siguiente en la que deberemos de seleccionar el tipo de conexión a generar. Si seleccionamos la opción de Web Service, se mostrará la siguiente pantalla, de la que seleccionaremos la opción de cliente AXIS que es sobre el que están hechos los servicios web con los que trabaja MCServer. 86 Seguidamente nos llevará a esta pantalla. Tendremos que seleccionar el paquete donde se encuentran los ficheros wsdl del servicio. Seleccionaremos la clase y el servicio deseado y pulsaremos Next. 87 Finalmente, escribiremos el nombre de la clase BL a generar, su ubicación, el nombre del método y el info que utilizará como salida. 88 89 4.- Controller Una vez creado un fichero de tipo controller, tendremos que poder configurarlo para su ejecución sobre la plataforma MCServer. 4.1.- Creación de una operativa Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar operative. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer. 4.2.- Creación de una micro operativa Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar micro operative. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer. 90 4.3.- Creación de una operativa guiada Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar guided Operative. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer como mostramos en la imagen. Además, para este tipo de operativas, se posee un editor gráfico para que resulte más sencillo su modelado. 4.4.- Creación de un outPutFilter Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar output Filter. 91 4.5.- Creación de un validation Para crear un elemento de este tipo, haremos click con el botón derecho sobre la operativa, New Child y elegiremos validation. Para editar sus propiedades lo haremos desde la pestaña inferior Propiedades. Para el caso de las operativas guiadas, se podrá crear el mismo objeto pero desde un editor gráfico. Seleccionamos en la paleta de la izquierda, el elemento validation y al hacer clic en la pantalla del editor, se mostrará un wizard como el que se adjunta a continuación. Asignaremos un nombre a la validación y seleccionaremos la operativa guiada sobre la que deseamos realizarla. 92 Una vez realizado esto, observaremos la siguiente pantalla donde introduciremos los parámetros a comprobar por el validation. Y al pulsar finalizar ya tendremos creada nuestro elemento. El aspecto final en el editor gráfico será el que mostramos en la imagen. Podremos editar el elemento haciendo click con el botón derecho. También podremos eliminar la conexión con la operativa guiada. 93 4.6.- Creación de un integration Para crear un elemento de este tipo, haremos click con el botón derecho sobre la operativa, New Child y elegiremos integration. Para editar sus propiedades lo haremos desde la pestaña inferior Propiedades. Para el caso de las operativas guiadas, se podrá crear el mismo objeto pero desde un editor gráfico. Seleccionamos en la paleta de la izquierda, el elemento integration y al hacer clic sobre la operativa, se mostrará un wizard como el que se adjunta a continuación. Asignaremos un nombre a el integration y un método, y añadiremos tantos integration data queramos. 94 4.10.- Creación de una clase CB Para crear un elemento de este tipo, haremos click con el botón derecho sobre la operativa, New Child y elegiremos guidance Class. Para editar sus propiedades lo haremos desde la pestaña inferior Propiedades. 4.11.- Generación de código de una clase CB Para la generación del código de la clase CB, haremos click con el botón derecho sobre la guidance class, y elegiremos Generar clase CB. Para poder generar el código de la operativa, necesitaremos tener creado un elemento validation con los parámetros que se desee validar. Al seleccionar esa opción del menú, se abrirá una pantalla como la siguiente para configurar la generación de la clase. 101 La pantalla siguiente permite la edición del resultInfo que devolverá la CB. 102 Y por último, la pantalla de configuración de la validación de la operativa, que nos permitirá añadir a la clase la generación de las constantes para cada atributo. Al presionar sobre Finish, se habrá generado dicha clase Java. 103 5.- View Una vez creado un fichero de tipo view, tendremos que poder configurarlo para su ejecución sobre la plataforma MCServer. 5.1.- Creación de una operativa Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar operative. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer. 5.2.- Creación de un form Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar form. También se puede crear el form automáticamente, presionando sobre la opción Diseñar vista. 104 5.3.- Creación de un source Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar Resource. En este parámetro, deberemos de indicar la ruta del fichero .xsl a mostrar por la aplicación. 5.4.- Creación de fields Para la creación de fields, se utilizará un editor gráfico muy intuitivo que permitirá editar las propiedades de todos los componentes del formulario. Para acceder a dicho editor, seleccionaremos la opción Diseñar vista, como se muestra en la imagen a continuación. 105 Para la creación de nuevas componentes del formulario, se deberá seleccionar el que se desee de la paleta de la izquierda. Seguidamente se abrirá una ventana emergente de configuración general del componente como la que mostramos a continuación, y que será común para todos ellos. También existirá una pantalla común para todos los componentes, que servirá para asignar acciones Javascript a cada subcomponente, como la que mostramos a continuación. 106 Y para la edición individual de las propiedades de cada subcomponente, presionando con el botón derecho sobre uno de ellos y seleccionando la opción Editar, se nos mostrará una ventana emergente similar a las de creación de un nuevo elemento. 107 A continuación, explicamos brevemente el proceso de creación de cada uno de los elementos del formulario. 5.4.1.- Label Para la creación de este componente, deberemos presionar en la paleta de la izquierda sobre el elemento Label. Seguidamente se nos abrirá una ventana emergente de configuración general del componente como se muestra en la introducción de este apartado. Después se mostrará una pantalla de configuración propia del componente como la que adjuntamos a continuación. Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 108 5.4.2.- Text Para la creación de este componente, deberemos presionar en la paleta de la izquierda sobre el elemento Text. Seguidamente se nos abrirá una ventana emergente de configuración general del componente como se muestra en la introducción de este apartado. Después se mostrará una pantalla de configuración propia del componente como la que adjuntamos a continuación. 109 Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 110 Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 117 5.4.7.- Radio Button Para la creación de este componente, deberemos presionar en la paleta de la izquierda sobre el elemento Radio Button. Seguidamente se nos abrirá una ventana emergente de configuración general del componente como se muestra en la introducción de este apartado. Después se mostrará una pantalla de configuración propia del componente como la que adjuntamos a continuación. 118 La pantalla siguiente nos permitirá añadir la lista de valores al radio button. 119 Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 120 5.4.8.- Check Box Para la creación de este componente, deberemos presionar en la paleta de la izquierda sobre el elemento Check Box. Seguidamente se nos abrirá una ventana emergente de configuración general del componente como se muestra en la introducción de este apartado. Después se mostrará una pantalla de configuración propia del componente como la que adjuntamos a continuación. 121 Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 122 5.4.9.- File Component Para la creación de este componente, deberemos presionar en la paleta de la izquierda sobre el elemento File Component. Seguidamente se nos abrirá una ventana emergente de configuración general del componente como se muestra en la introducción de este apartado. Después se mostrará una pantalla de configuración propia del componente como la que adjuntamos a continuación. 123 124 Finalmente, el aspecto del componente en el formulario será similar al que mostramos a continuación. 125 6.- Ejbs Una vez creado un fichero de tipo ejbs, tendremos que poder configurarlo para su ejecución sobre la plataforma MCServer. 6.1.- Creación de una conexión Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar connection. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer. 6.2.- Creación de un EJB Deberemos abrir el fichero en Eclipse, haciendo doble clic sobre él. Seguidamente, hacer click con el botón derecho, New Child y seleccionar ejb. También deberemos de asignarle las propiedades necesarias para su correcto funcionamiento en MCServer. 126