3. SISTEMA DESARROLLADO Dominio del problema Introducción Glosario de términos Requisitos del sistema

Transcripción

1 Índice general 1. INTRODUCCIÓN Introducción Motivación Objetivos del proyecto Objetivos definidos para la realización del proyecto Desarrollo del proyecto MATERIAS RELACIONADAS Conceptos Modelo Vista Controlador Persistencia de datos Canales RSS Herramientas para el desarrollo REM Eclipse Lomboz TortoiseSVN Apache Tomcat PostgreSQL DBVisualizer TexnicCEnter

2 3. SISTEMA DESARROLLADO Dominio del problema Introducción Glosario de términos Requisitos del sistema LsiWeb Participantes del proyecto Descripción del sistema actual Objetivos del sistema Requisitos del sistema Matriz de rastreabilidad Análisis del sistema LsiWeb Modelo estático y tipos Modelo dinámico Interfaz de usuario Diseño del sistema Puntos de variación y evolución Puntos de variación Puntos de evolución Arquitectuta del sistema Implementaciíon del sistema Entorno de desarrollo Componentes más importantes Pruebas del sistema Pruebas de funcionalidad Pruebas de carga Pruebas de usuario Instalacion

3 3.10. Manual CONCLUSIONES Cumplimiento de los objetivos Esfuerzo empleado en el proyecto BIBLIOGRAFÍA Bibliografía y referencias

4 Capítulo 1 INTRODUCCIÓN 4

5 1.1. Introducción Aquí escribiremos la intro Motivación La principal motivación a la hora de realizar el proyecto es la de poder llevar a la práctica aquellos conocimientos de las máterias que mas me han llamado la atención a lo largos de los distintos curso de la carrera. El desarrollo web es una de las áreas más emergentes en nuestros días, por ello siempre he tratado de profundizar en este tema escogiendo asignaturas optativas relacionadas o mayor o menor medida. El desarrollo de la asigntura de Proyecto Informático me ofrecía la posibilidad de escoger un tema libre en cuanto a contenido a y las tecnológias a emplear. Por ello decidí hacer una aplicación web, el tema sobre el que versa la aplicación quería que fuese conocido para poder centrarme principalmente en la tecnología a emplear unaque obviamente en toda aplicación que se desarrolla lo principal y es la funcionalidad que se ofrece al cliente y aún más importante si cabe es la utilidad que el cliente le dé a nuestra aplicación. Con estas dos ideas relacionadas decidí centrarme en la realización de una aplicación web para el Departamento de Lenguajes y Sistemas Informáticos, principalmente en el módulo relacionado con la docencia, ya que abarcar todos los módulos se saldría de la limitación temporal de las normas del PFC. Mi motivación personal era poder realizar una aplicación desde todos los puntos de vista, es decir, desde que se elicitan los requisitos con el cliente (en este caso con mi tutor del proyecto) hasta la presentación del proyecto, pasando por el análisis diseño y desarrollo del la aplicación. En el próximo apartado se explicarán los objetivos que se plantean a la hora de la realización de este proyecto: Objetivos del proyecto Independientemente de los objetivos propios de la aplicación desarrollada, la realización del proyecto tiene como objetivo la formación en las nuevas herramientas y frameworks usados en la actualidad para el desarrollo web 5

6 aplicando los conocimientos teóricos aprendido a lo largo de la carrera. Como objetivo principal nos planteamos desarrollar una aplicación para el LSI usando J2EE. El enfoque de la aplicación no es el de la migración de la tecnología actual (MySQL y PHP), sino el del desarrollo desde 0 aplicando la tecnología J2EE. La tecnologías elegidas para el aprendizaje y su uso posterior en el desarrollo del proyecto son las siguientes: Struts2 Este framework implementa el modelo vista controlador, implementa el patrón FrontControler, que aporta una solución al problema de las peticiones de los distintos recursos comunes de la aplicacicón. Struts realiza esta tarea y actúa de controlador frontal despachando las peticiones que se hagan a los distintos recursos de la aplicación. JSTL: Para la capa de presentación, se ha decido usar JSTL como solución a JSP para que la capa de presientación no solape la logica de negocio (LN) tal y como sucedería si se usara JSP. JSTL nos aporta dicha separación con la implementación de los Taglibs necesarios para tratar el contenido procedente de la LN que alimenta a la capa de presentación. Hibernate: Este framework implementa la capa de persistencia de datos, y su función es busca solucionar el problema de la diferencia entre los dos modelos de datos coexistentes en una aplicación: el usado en la memoria de la computadora (orientación a objetos) y el usado en las bases de datos (modelo relacional). Para lograr esto permite al desarrollador detallar cómo es su modelo de datos, qué relaciones existen y qué forma tienen. Con esta información Hibernate le permite a la aplicación manipular los datos de la base operando sobre objetos, con todas las características de la POO. DOJO Toolkit Este framework nos aporta una visualización de los elementos Html de la capa de presentación basándose en la tecnología asincrona AJAX. Conocimientos Principalmente debemos conocer la arquitectura sobre la cual vamos a desarrollar a nivel de capas, en este proyecto se hará una implementación en 3 capas que son las de presentación, logica de negocio y la capa de persistencia de datos. A ellas nos referiremos a lo largo de este documento como capa de presentación, logica de negocio y capa de datos respectivamente. Para llevar a cabo la implementación del proyecto es necesario el conocimiento del funcionamiento básico de una aplicación web y los problemas que esta 6

7 plantea la tecnología sobre la que subyacen el conjunto de lenguajes y herramientas a la hora de desarrollar: Para la capa de presentación trabajando con HTTP se plantea el problema del estado, ya que HTTP sin estado. Este problema de entre las mutiples soluciones posibles (uso de sesiones, formularios ocultos,...) se soluciona con la implementación de un Servlet. Otro problema importante que se plantea a lo hora del desarrollo es la comunicación entre la aplicación y los datos. Existen los drivers JDBC que serán los que en nuestro caso realizan dicha tarea. Formación Ha sido necesaria la Formación en los Struts e Hibernate. Esta formación se ha realizado la documentación oficial y las API de estos frameworks, así como de distintos foros relacionados encontrados para solventar problemas concretos de la implementación e integración con la aplicación Objetivos definidos para la realización del proyecto Esta formación está constituida por las siguientes fases: Prioridad Alta -cambiar esto de abajo Gestión de Usuarios En la aplicación iteractuarán tres usuarios con distintos roles: Gestor de la aplicación: Actuará como super usuario y será el encargado de de la creción de asignaturas y la gestión del resto de usuarios(profesores). Además tendrá control total sobre las asignaturas dadas de alta en la aplicación. Coordinador de una asignatura: Cada asignatura tendrá un coordinador que será el encargado de editar el contenido de dicha asignatura Profesor de una asignatura: Tendrá acceso a los datos de la asignatura y será en encargado de subir noticias y nuevos materiales docentes. Alumno: Tendrá acceso a los datos de la asignatura y será en encargado de subir noticias y nuevos materiales docentes. 7

8 NOTA: el usuario que actua como alumno no interactua con la aplicación, solamente podrá consultar el contenido editado por el resto de usuarios. Gestión de noticias: Cada asignatura generará noticias que se publicarán mediante un canal RSS asociado a cada una de las noticias. Gestión de material Docente: A cada asignatura se le podrá añadir documentación que podrá ser descargada por el usuario final (alumno). También se añadirá la funcionalidad de descargar toda la documentación perteneciente a una asignatura en formato.zip. Prioridad Media Gestión de Horarios de Tutorias Cada profesor de la asignatura podrá gestionar desde la aplicación su información personal publicar sus horarios de tutorias disponibles. Gestión de Notificaciones El coordiandor de la asignatura podrá notificar a los alumnos que se hayan inscrito en la asignatura mediante de informaciones relevantes que se produzcan en la asignatura Prioridad Baja Gestión de Tutorias El alumno que se haya inscrito en la asignatura podrá realizar una peticion de una cita de tutoría a un profesor de su asignatura Desarrollo del proyecto Para el desarrollo del proyecto tube dos reuniones con mi tutor del proyecto en las que, en la primera de ellas se plantearon todos aquellos objetivos que podrían ser abarcables dentro del ámbito en el que se mueve la aplicación. El objetivo de esa reunión era ver todo aquello que se podrá ser interesante realizar independientemente de las dificultades tecnologicas futuras que se pudiesen plantear. Tras esa reunión se valoró el coste temporal que tendría llevar a cabo cada uno de los requisitos que se desprendían del los objetivos iniciales planteados. En la segunda reunión se volvirieron a plantear los objetivos pero ya con un coste en horas de los que sería el desarrollo total del proyecto, para así priorizarlos en función de su importancia. Como se puede ver en el apartado de 8

9 Figura 1.1: Planificación de costes (en horas) objetivos se priorizaron en prioridad alta, media y baja. Una vez concretados los objetivos se hizo un ánalisis de impactos de los cambios que se introdujeron. Trasel análisis de impactos se retificó con los objetivos definitivos eran asumibles en el desarrollo sin salirnos de la planificación en horas del proyecto. Dicha palanificación en horas está sujeta a las propias normas que define la ETSII para la realización de la asignatura de Proyecto Informático. Se ha definido un procediento de actuación, a continuación se describe cuales han sido las pautas a seguir para llevar a cabo el desarrollo del proyecto: 9

10 Capítulo 2 MATERIAS RELACIONADAS 10

11 2.1. Conceptos Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones Web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página Modelo Vista Controlador Modelo: Esta es la representación específica del dominio de la información sobre la cual funciona la aplicación. El modelo es otra forma de llamar a la capa de dominio. La lógica de dominio añade significado a los datos; por ejemplo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Figura 2.1: Patrón Modelo Vista Controlador Wikipedia Persistencia de datos Es usual trabajar con programación orientada a objetos y utilizar bases de datos (BD) relacionales. Resulta obvio que se trata de dos paradigmas difer- 11

12 entes. El modelo relacional trata con relaciones, tuplas y conjuntos, y es muy matemático por naturaleza. El paradigma orientado a objetos, sin embargo, trata con objetos, sus atributos y relaciones entre objetos. Cuando se quiere hacer que los objetos sean persistentes utilizando para ello una BD relacional, uno se da cuenta de que hay una desavenencia entre estos dos paradigmas: es lo que se denomina un object-relational gap Canales RSS RSS es una familia de formatos de fuentes web codificados en XML. Se utiliza para suministrar a suscriptores de información actualizada frecuentemente. El formato permite distribuir contenido sin necesidad de un navegador, utilizando un software diseñado para leer estos contenidos RSS (agregador). A pesar de eso, es posible utilizar el mismo navegador para ver los contenidos RSS. Las últimas versiones de los principales navegadores permiten leer los RSS sin necesidad de software adicional. RSS es parte de la familia de los formatos XML desarrollado específicamente para todo tipo de sitios que se actualicen con frecuencia y por medio del cual se puede compartir la información y usarla en otros sitios web o programas. A esto se le conoce como redifusión web o sindicación web (una traducción incorrecta, pero de uso muy común). Muestra aplicación usuará este tipo de formatos para compartir la información de mayor relevancia que sea publicada Herramientas para el desarrollo REM Herramienta para el desarrollo de la elicitación de requisitos y análisis del sistema. Desarrollado por Amador Durán Toro Eclipse Lomboz Es un IDE de desarrollo en el que entontramos integrados los principales framworks de desarrollo usados en la actualidad. En ella se desarrolla el código de la aplicación. Dicha aplicación integra en el mismo IDE el contenedor web sobre el que se está desarrollando, permitiendo mayor agilidad durante el desarrollo así como la ejecución en modo debugger, muy útil para la detección de errores. 12

13 plugins instalados Se ha instalado el plugin Subclipse 1.4 proyecto (proyecto Open Source Tigris). Esté plugin funciona sobre un cliente de Subversion por defecto que trae incorporado el propio plugin y sobre el cliente de subversión que tengamos instalado, por ejemplo Tortoise. Subclipse permite conectar con nuestro repositorio SVN y hacer las acciones típicas sobre el repositorio de código, commit, update, revert... Dichas operaciones se describi rán posteriormente cuando hablemos de la herramienta Tortoise, que será el cliente de subversion utilizado TortoiseSVN Para la gestión de nuestro repositorio de código hemos usuado el cliente de Subversion TortoiseSVN En cuanto al funcionamiento de un cliente SVN las operaciones que realizaremos serán: Commit: Subir nuevos cambios, se generá un nuevo codigo (llamado revision) y se mantiene un hisórico de los cambios anteriores. Por convenio se hará commit siempre versiones sin fallos para que la versión de la aplicación funcione. Update: Traemos a nuestro local los cambios que se hayan hecho en el repositorio. Normalmente por otra persona que esté desarrollando desde otra ubicación. Revert: Nos traemos a nuestro local la última versión subida al repositorio. (útil cuando queremos deshacer cambios). Importante: Para el correcto funcionamiento de nuestro cliente de Subversion con el plugin Subclipse la ver sión que se utilice para estar actualizada ya que de no estarlo se Subversion bloquearía el fichero comiteado no permiendo volver a actual sobre él. (Habría borrar el enlace a SVN, hacer cleanup del proyecto y volver a verionar el fichero bloqueado con el nuevo cliente de Subersion). Para evitar esto se recomienda por ejemplo si usamos TortoiseSVN 1.6, usar el cliente de Subclipse 1.4 ó superior Apache Tomcat Se ha usado Tomcat como servidor de aplicaciones. En el apartado de Arquitectura del Sistema se detallará detenidamente cual es su funcionamiento. 13

14 PostgreSQL Para el desarrollo de nuestra aplicación se ha elegido usar como sevidor de Base de Datos PostgreSQL. Como Gestor se ha usado pgadminiii que es el gestor por defecto de PostgreSQL. El funcionamiento del servidor de Base de Datos se detallará con mayor profundidad en el apartado de Arquitectura del Sistema DBVisualizer Se ha usuado además del gestor PgAdminIII como herramienta de ayuda a la hora de hacer el diseño de la aplicación a nivel de Base de Datos, aprovechando la funcionalidad que nos da DBVisualizer para visualizar de forma gráfica las tablas así como las relaciones existentes entre ellas TexnicCEnter TeXnicCenter es un editor software libre de LaTeX para Windows, el cual integra en sí mismo las herramientas necesarias para la composición de texto científico, desde una ventana de compilación integrada. Para la compilación de codigo escrito en latex (Código fuente, formato.tex) se requiere Miktex. Para la compilación de este documento se ha usado MikTex2.8 MikTex2.8 MiKTeX es una distribución TeX/LaTeX para Microsoft Windows 14

15 Capítulo 3 SISTEMA DESARROLLADO 15

16 3.1. Dominio del problema Para la gestión del contenido de la docencia de un departamento, en nuestro caso concreto el Departamento de Lenguajes y Sistemas Informáticos, se requiere mostrar la información de una forma ordenada y de fácil acceso para el usuario final. También se necesaria la edicion y personaliza ción de cada asignatura, ya que la información que se presenta es sucpectible de cambio en cualquier momento debido a su propia naturaleza Introducción El sistema desarrollado es una aplicación web que permite a los distintos usuarios de la aplicación publicar información y/o obtenerla, según el rol del usuario en cuestión. El elemento principal de nuestra aplicación serán las asignaturas, que contendrán la informacíon relevante para el usuario. Dicha información se servirá a través del navegador web o la publicación de noticias mediante canales RSS. La información que se muestra en cada uno de los epígrafes de la asignatura será editable, bien por el coordinador de la asignatura o el gestior de la apliciacíon. También serán editables los epigrafes que se mostrarán en cada asignatura Glosario de términos RSS: Es una familia de formatos de fuentes web codificados en XML Requisitos del sistema LsiWeb 16

17 Participantes del proyecto Organizaciones Participantes Descripción del sistema actual descripcion mas el diagrama bpmn 17

18 Objetivos del sistema 18

19 Requisitos del sistema Requisitos de Información 19

20 20

21 21

22 Requisitos Funcionales Diagrama de casos de uso: Actores del sistema: 22

23 23

24 Casos de uso del sistema: 24

25 25

26 26

27 27

28 28

29 29

30 Matriz de rastreabilidad Figura 3.1: Objetivos - Requisitos de Información 3.3. Análisis del sistema LsiWeb Modelo estático y tipos Figura 3.2: Modelado Estático y tipos 30

31 Modelo dinámico Interfaz de usuario 3.4. Diseño del sistema En cuanto al diseño de la aplicación, se ha hecho de abajo-arriba(bottomup) en el que primero se definió la funcionalidad desde el punto de vista del cliente, este diseño nos ofrece la ventaja de poder empezar desde cero el diseño, por lo que nos aprovecharemos de esta circunstancia para procurar que los componentes estén lo menos acoplados posible. En cuanto al esquema de base de datos se ha realizado un modelado que permita llevar a cabo los requisitos funcionales, organizando la información en tablas y relacionándolas con FK a través de la PK correspondiente que identifique cada tabla. El modelo esta en tercera forma normal (3FN) evitando así la información duplicada o redundante. Desde la aplicación accedemos a la BD usando el framework de Hibernate de persistencia de datos. Nuestra aplicaciíon se comunica con la BD usando el driver de JDBC ofrecido por el fabricante de nuestra BD PostgreSQL. En cuanto a la forma de obtener los datos, se hace mediante el patrón DAO, cuyo objetivo es abstraer y encapsular todos los accesos a la fuente de datos. Esta patrón se ha implementado contra interfaces, usando una clase tipo Service que será la encargada de obtener la instancia del objeto DAO. Con esta separación se consigue eliminar el acoplamiento de la aplicación con la BD utilizada. Si en un futuro se quisiese migrar a usar otra BD, sólo sería necesario modificar el código de los objetos DAO. Por ejemplo, si se quisiese pasar a usar una Oracle o SQLServer,tendrcambiaríamos el driver JDBC, y realizar cambios en la implementación de los DAO ya es estas BD no usan un SQL estandar.si se migrase por ejemplo MySQL, solo habría que cambiar el driver JDBC ya que MySQL y PostgreSQL utilizan SQL estandar. Vemos ahora el diagrama de clases que representa la utlización del patrón DAO con interfaces: 31

32 Figura 3.3: Implementación patrón DAO En cuanto al diseño realizado para la implementación, (Vease diagrama de paquetes), se ha usado el framwork Struts para implementar el modelo MVC. Definimos a continuación el Modelo, la Vista y el Controlador en nuestra aplicación: Modelo: Lo implementan los ficheros *.java. Se denominan actions y representan la información con la que nuestro sistema opera. En ellos opera con los datos y se asegura la integridad de los mismos. Los actions suelen operar con los denominados forms para cargar o descargar la información servida o recogida desde la capa de presentación. Vista:Son los ficheros *.jsp que son los encargados de mostrar la información obtenida desde la LN al usuario de una manera sencilla y amena. Para la implementación de de la vista se usa el lenguaje JSTL, que es un lenguaje de script que mediante Taglibs ofrece al desarrollador las herramientas necesarias para obtener los datos de la LN y muestrarlos en el navegador. JSTL está bastante acoplado con Struts, por lo que se recomienda su uso cuando se esta desarrollando con este framework. Controlador: Lo implementa el fichero struts-config.xml que es el encargado de atender y despachar las peticiones a los distintos recursos de la aplicación. La Lógica de negocio está ligeramente acoplada al framework Struts, ya que no se ha considerado susceptible la migración a otro framework como podría ser Spring ó Velocity. No obstante, si se quisiera llevar a cabo dicha migración se deberían de realizar cambios en los ficheros que implementan los actions de la aplicación. Los cambios a realizar serían leves, puesto que el acoplamiento con el framework sólo en que el código que implementa la LN está en la 32

33 Figura 3.4: Implementación del modelo MVC en la aplicación misma clase que implementa el Modelo, por lo que se debería de aplicar la refactorización Extract Class para tener una clase en el que exclusivamente se hagan las operaciones propias de la lógica de negocio de nuestra aplicación y la otra clase excluivamente implementaría el modelo del framework elegido. Hecha esta refactorización estaría desacoplada la LN de nuestra aplicación con el framworks utilizado. 33

34 Diagrama de paquetes: En el siguiente diagrama vemos los paquetes y sus dependencias: Figura 3.5: Diagrama de paquetes de la aplicación 34

35 3.5. Puntos de variación y evolución Puntos de variación Puntos de evolución 35

36 3.6. Arquitectuta del sistema La arquitectura del sistema es un diseño en 3 capas que permite separar el capa de presentaciń, la capa de logica de negocio y la capa de datos. Este diseño en 3 capas presenta muchas ventajas... Diseño en 3 capas Figura 3.6: Diagrama dedespliegue 36

37 Diagrama de despliegue A continuación mostramos el diagrama de despliege de la aplición: Figura 3.7: Diagrama dedespliegue Diagrama de nodos Vemos en el siguiente diagrama la arquitectura 3-tiers: 37

38 El nodo que representa al servidor de aplicaciones y el servidor de base de datos podría ser uno solo, dependiendo de las caracteristicas de las máquinas que se dispongan para la instalación y sus caracteristicas. Se recomienda separar el servidor de aplicaciones del servidor de base de datos por rendimiento y por temas de seguridad frente a una posible caida de uno de los servidores. Estando separados ambos nodos será más fácil y rapido restaurar el sistema. 38

39 3.7. Implementaciíon del sistema Entorno de desarrollo Componentes más importantes 3.8. Pruebas del sistema Pruebas de funcionalidad Pruebas de carga Pruebas de usuario 3.9. Instalacion Manual 39

40 Capítulo 4 CONCLUSIONES 40

41 4.1. Cumplimiento de los objetivos 4.2. Esfuerzo empleado en el proyecto 41

42 Capítulo 5 BIBLIOGRAFÍA 42

43 5.1. Bibliografía y referencias 43