ARQUITECTUA DE M2M MIGUEL ÁLVAREZ Y CLARA HERRERO. Documento inicial

Transcripción

1 Título ARQUITECTUA DE M2M Proyecto Monkey to Monkey ( M 2 M ) Equipo Proyectos Informáticos Versión 1.0 Código PLAN_M2M_2012_04_01 Fecha 19/04/2012 Autores MIGUEL ÁLVAREZ Y CLARA HERRERO Estado Documento inicial Resumen Este documento presenta una definición de la arquitectura para la aplicación Monkey to Monkey ( M 2 M )

2 INDICE 1 INTRODUCCIÓN TECNOLOGÍAS ARQUITECTURA POR CAPAS Decisiones sobre la arquitectura 5 4 ESTÁNDARES LENGUAJES DISEÑO DIAGRAMAS UML BIBLIOGRAFÍA... 12

3 ARQUITECTUA DE M2M 1 INTRODUCCIÓN La aplicación m2m tiene una función clara de difusión entre una amplia comunidad de usuarios, de distintos países y distintos niveles técnicos. Esta aplicación será utilizada a través de los navegadores de los propios usuarios. Por esta razón se va a realizar bajo un modelo que libere al usuario de posibles instalaciones en su equipo, y además tenga en cuenta que pueda ser internacionalizable, así como fácilmente escalable en lo que a interfaz de usuario se refiere. 2 TECNOLOGÍAS Se va a desarrollar sobre la plataforma J2EE (Java 2 Enterprise Edition), que nos proporciona las herramientas que consideramos adecuadas para una aplicación web. El controlador se implementa mediante el framework Struts de Apache. Proporciona una implementación del patrón MVC basada en un único controlador (ActionServlet) que dirige las peticiones del usuario a clases de acción específicas (Action) mediante un archivo configurable (struts-config.xml) que sería nuestro mapa de correspondencias entre peticiones y acciones. De esta manera vamos a delegar la gestión de las peticiones a este controlador. En la decisión de uso de este framework también incurre la posibilidad de internacionalización de mensajes. La lógica de negocio de la aplicación se presenta en clases Java simples (también denominados POJO o Plan Java Objects). Para el acceso a la base de datos se utiliza JDBC, además se ha decidido utilizar persistencia, más concretamente Hibernate. La capa de presentación se implementa mediante tecnología JSP (Java Server Pages) que permite a los programadores generar contenido dinámico para web mezclando HTML estático y el generado de los servlets. Además se posibilita la adaptación a formatos para distintos dispositivos mediante el uso de hojas de estilo CSS. 3 ARQUITECTURA POR CAPAS La aplicación se construye siguiendo una arquitectura basada en el modelo Model View Controller (MVC). Este patrón de diseño establece que los elementos deben situarse en diferentes niveles según su naturaleza (ver figura). 3

4 ARQUITECTUA DE M2M Nivel de modelo (Model). En este nivel se sitúan todos los elementos relacionados con las reglas que rigen el comportamiento. Se divide en dos capas: o Capa de datos: contiene la descripción de los almacenes de datos, así como la lógica que permite el acceso a los mismos para lectura o escritura. o Capa de lógica de negocio: Codifica las reglas de funcionamiento. Nivel de controlador (Controller). Interacción entre la aplicación y el usuario. Nivel de presentación (View). Aspectos de interfaz de usuario de la aplicación, tanto en lo referente a diseño de páginas como las funcionalidades que ofrecen. Esta ha sido una definición general que podríamos aplicar a otras aplicaciones. Particularmente para m2m vamos a tener: - Componente para la gestión del modelo de datos: Paquete DAO - Componente de lógica de negocio: Paquete BL - Componente de controlador: Paquete ACTION - Componente a nivel de presentación: Paquete WEB 4

5 ARQUITECTUA DE M2M 3.1 Decisiones sobre la arquitectura La arquitectura MVC tiene la distribución de componentes que muestra la figura. En primera instancia, se había pensado en una estructura de paquetes que correspondiera con los objetos lógicos de la aplicación (por ejemplo, un paquete mensajes que incluyera la acción, la lógica de negocio, lógica de acceso a datos y POJO). Sin embargo, basándonos en la arquitectura MVC vamos a subdividir cuatro componentes, que son los correspondientes a las capas anteriormente descritas. Si estos a su vez los dividimos en cada ámbito (por ejemplo mensajes, alertas, usuarios ) tendremos prácticamente un paquete por clase. Por lo tanto, no vamos a hacer esta subdivisión. 5

6 + Ventajas - Desventajas Al obligar a dividir (escalabilidad) facilita la posterior reutilización del código y también la modificación de alguno de los componentes sin perjuicio para el resto Facilita añadir filtros Especialización del código según funciones de la capa, podemos asignar programadores según su mayor conocimiento en la capa en cuestión Mayor número de clases y por lo tanto de intersecciones Dificultad para entender el modelo de arquitectura Las posteriores correcciones de bugs pueden resultar complicadas a la hora de identificar la raíz del problema Simplifica identificación de resultados esperados, lo que facilita la integración con el paquete Junit y creación de Test Unitarios

7 ARQUITECTUA DE M2M Para resolver el problema de complejidad, hemos decidido que detallaramos en esta documentación, las clases pertenecientes a cada ámbito (por ejemplo Mensajes, Usuarios, Anuncios ) y en cada componente vamos a tener una clase al menos de este tipo, teniendo por lo tanto n componentes x m al menos. Esto que parece complicado lo vamos a ver de forma sencilla con un ejemplo (nota: es un ejemplo, no corresponde a todo el esquema de la aplicación): Componentes: ACTION, BL, DAO, VISTA Ámbitos: Mensajes, Usuarios Clase resultantes: - ACTION.mensajes - BL.mensajes - DAO.mensajes - VISTA.mensajes Podemos ver estas cuatro clases como un único ente, que se encarga de las operaciones relacionadas con los mensajes. Clases del ámbito usuario. - ACTION.usuarios - BL.usuarios - DAO.usuarios - VISTA.usuarios Dentro del ACTION y relacionadas con usuarios podemos tener, por ejemplo, las clases RegistroAction, LoginAction y ManagerAction. Si a lo largo del desarrollo aparece la necesidad de creación de alguna clase nueva que no se ha descrito en este documento, se evaluará si fuera necesario otro paquete o si la incluimos en alguno de los que ya tenemos, además la incluiremos en los diagramas ya existentes. Otro caso que se puede dar, es que en la acción de un ámbito utilicemos algún método no definido en su BL, pero que se ha desarrollado para otro ámbito y nos sea de utilidad. No vamos a reescribir el método, sino que instanciaremos la clase BL en la acción y utilizaremos el 7

8 ARQUITECTUA DE M2M método oportuno. Por ejemplo, si tenemos MensajesAction y queremos utilizar un método de AnunciosBL. - Restricciones: No saltarse ninguna capa, es decir, aunque parezca obvio hacer una consulta desde el Action para conseguir alguna información sencilla, habrá que hacer un método por capa. Es decir, llamaremos al método del BL que llamara al método del DAO que se encargará de hacer la consulta. 4 ESTÁNDARES - Estándares Java: Cumplir con los estándares de nomenclatura. Si queda alguna duda, consultar el siguiente enlace - Versiones: Habrá una versión por cada prototipo documentado en el calendario de prototipos (Calendario 1 -> v.1, Calendario 2 > v.2) 5 LENGUAJES Java. Orientado a Objetos, utilizado en la aplicación. CSS. Para la definición de las hojas de estilos utilizadas en los fuentes HTML. HTML. Para la realización de maquetas y la estructura de las páginas web diseñadas. JavaScript. Como lenguaje interpretado dentro de las páginas web. XML. Para la definición de los ficheros de configuración y tareas Ant. HQL. Para consultas a la base de datos. 8

9 6 DISEÑO En base al análisis de requisitos y las decisiones sobre la arquitectura tenemos las siguientes clases java y páginas jsp: - Relacionados con ámbitos COMPONENTE > ACTION BL DAO VISTA AMBITO BASE BaseAction BaseForm BaseDao Cabecera.jspf Pie.jspf Error.jspf menusup.jspf menulateral.jspf content.jspf USUARIOS RegistroAction RegistroForm UsuariosBL UsuariosDAO Registro.jsp LoginAction LoginForm Login.jsp AdminUsuariosAction AdminUsuariosForm adminusuarios.jsp modificardatosusuario.jsp PREFERENCIAS PreferenciasAction PreferenciasForm PreferenciasBL PreferenciasDAO verpreferencias.jsp anyadirpreferencia.jsp HORARIOS HorariosAction HorariosForm HorariosBL HorariosDAO verhorarios.jsp modificarhorarios.jsp

10 CONOCIMIENTOS AdminCategoriasAction AdminCategoriasFor CategoriasBL CategoriasDAO admincategorías.jsp ConocimientosAction m ConocimientosBL ConocimientosDAO adminconocimientos.jsp ConocimientosForm vermodificarmisconocimientos.jsp SUGERENCIAS SugerenciasAction SugerenciasForm SugerenciasBL SugerenciasDAO versugerencias.jsp CONTACTOS ContactosAction ContactosForm ContactosBL ContactosDAO vercontactos.jsp ALERTAS AlertasAction AlertasForm AlertasBL AlertasDAO vermodificaralertasgestion.jsp verinstanciasdealertas.jsp ANUNCIOS AnunciosAction AnunciosForm AnunciosBL AnunciosDAO veranuncios.jsp veranunciosadmin.jsp INTERCAMBIOS IntercambiosAction IntercambiosForm IntercambiosBL IntercambiosDAO verintercambios.jsp MENSAJES MensajesAction MensajesForm MensajesBL MensajesDAO vermensajes.jsp enviarmensaje.jsp TUTORIALES TutorialesAction TutorialesForm TutorialesBL TutorialesDAO buscartutoriales.jsp vertutorial.jsp vermistutoriales.jsp insertartutorial.jsp EVALUACIONES EvaluacionesAction EvaluacionesForm EvaluacionBL EvaluacionDAO anyadirevaluacion.jsp detalleevaluacion.jsp

11 - Generales COMPONENTE PAQUETES CLASES MODELO Usuario Preferencias Horario Conocimiento Sugerencia Contacto Alerta AlertaGestion Anuncio Intercambio Mensaje Tutorial Evaluacion UTILS Constantes Transformaciones

12 ARQUITECTUA DE M2M 7 DIAGRAMAS UML Diagramas de clases: Por la extensión de los diagramas, se han generado mediante Netbeans 6.5 con el plugin UML y se ha generado un reporte visible mediante cualquier navegador que se adjunta comprimido a continuación. Descomprimir y ejecutar index.html Report.rar 8 BIBLIOGRAFÍA Como documentar una arquitectura Explicación de las clases de struts junto con algunos diagramas UML que merece la pena ver Curso sobre Jakarta Struts ftp://jano.unicauca.edu.co/maestria/cursos/aplicacionesinternet/docs/struts.pdf Implementación Creación de un formulario Tutorial for struts internationalization ( I18N ): Securing Struts Applications

13 ARQUITECTUA DE M2M Módulos para el manejo de tablas y paginación