Descripción de Arquitectura Repositorio de metadatos de componentes de software

Transcripción

1 Descripción de Arquitectura Repositorio de metadatos de componentes de software 1. Introducción Propósito Alcance Definiciones. 1.4 Contexto Referencia. 2. Objetivos y restricciones de la arquitectura. 3. Arquitectura y ventajas. 4. Identificación de StakeHolders y Objetivos. 4.1 Usuarios del sistema Perspectiva frente al sistema. 4.2 Desarrolladores del Sistema Perspectiva frente al sistema. 4.3 Viabilidad de la construcción del sistema. 4.4 Riesgos y operación del sistema (Operación de los stakeholders) 4.5 Instalación y evolución del sistema Posibles evoluciones de la arquitectura propuesta para proyectos posteriores. 5. Definición de puntos de vista por stakeholder. 6. Definición de vistas. 6.1 Consistencia entre puntos de vista. 7. Modelos arquitectura.

2 1. Introducción 1.1. Propósito Este documento pretende dar a conocer la estructura de la arquitectura del repositorio de metadatos de componentes de software, para lo cual utilizaremos diferentes vistas de los stakeholders que puedan mostrar los aspectos más importantes del sistema Alcance El alcance del documento es dar una visión global de la arquitectura del repositorio de metadatos de componentes, con el fin de cumplir las diferentes funcionalidades del sistema, definidas con anterioridad en el documento de requerimientos, enfocándonos principalmente en construir un sistema robusto, así como también permitir ser extensible a futuros desarrollos. 1.3 Definiciones Objetivos: Son los intereses particulares de cada unos de los stakeholders frente al Sistema. Puntos de vista: Es la agrupación de objetivos comunes que pueden tener diferentes Stakeholders frente al sistema Vistas: Es la agrupación de puntos de vista en modelos generales que buscan definir y agrupar la totalidad de objetivos. La agrupación de vistas definen la arquitectura del sistema. 1.4 Contexto Se analizará la arquitectura desde el punto de vista de los usuarios y los desarrolladores, principalmente sus intereses frente al sistema, también se tendrán en cuenta definiciones más detalladas tales como funcionalidades y conexiones entre las diferentes capas de la arquitectura propuesta. 1.5 Referencias IEEE Std , IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

3 Pressman, Roger S, Ingeniería de software un enfoque practico, Mc Graw Hill, Objetivos y Restricciones de la Arquitectura Es importante tener en cuenta los requerimientos más importantes y restricciones que afectaran la arquitectura del sistema, como son: La aplicación debe soportar multiplataforma para el acceso de los usuarios. Esta será ejecutada a través de un navegador de Internet. El sistema manejará la persistencia de datos a través de una base de datos relacional Oracle 9i o SQL Server El sistema poseerá seguridad para los datos que se almacenan en el mismo, de modo que en el diseño de la arquitectura se deben tener en cuenta restricciones de autenticación y autorización principalmente para los publicadores de componentes. Los requerimientos que se establecieron en el documento de Especificación de requerimientos deben ser tenidos en cuenta. 3. Arquitectura y ventajas. La arquitectura escogida para el desarrollo del proyecto es J2EE ya que soporta las características de robustez y escalabilidad de acuerdo a los requerimientos definidos previamente. Acceder a la aplicación a través de un Browser. Soportar conexiones concurrentes, incluyendo solicitudes a la base de datos en cualquier instante de tiempo. Permitir desarrollos posteriores en cuanto a la transaccionalidad de documentos XML, acceso a componentes de forma directa o link al proveedor principal. 4. Identificación de StakeHolders y Objetivos

4 Los stakeholders identificados para el repositorio de metadatos de componentes de software son: usuarios del sistema, proveedores y desarrolladores del sistema Usuarios del sistema Los usuarios del sistema serán en primera instancia las PyMEs del sector de Transmisión de datos a través de redes y cualquier otra entidad o persona que pudiera estar interesada en la consulta de componentes Perspectiva frente al sistema. Los usuarios del sistema buscan un acceso vía Web al repositorio con el fin de consultar los componentes de acuerdo a su funcionalidad, tipo de arquitectura y lenguaje de programación (De acuerdo a los resultados de las encuestas realizadas). Las consultas deberán ser sencillas y permitir delimitarlas de acuerdo a las principales características de los componentes tales como funcionalidad, tipo de arquitectura y lenguaje de programación. La interfaz de comunicación con el sistema debería ser sencilla en cuanto al acceso a las funcionalidades de consulta Proveedores. Serán los encargados de ingresar la descripción de componentes que se deseen encontrar a través de la biblioteca Perspectiva frente al sistema Facilidad de ingreso de información básica del componte a través de la interfaz Web Desarrolladores del sistema Los desarrolladores del sistema somos Rodrigo Fonseca y Dawid Junnco. Somos los encargados de analizar los requerimientos definidos por el sector de las PyMEs seleccionado por el estudio previo Perspectiva frente al sistema.

5 Nuestro interés se centra en definir una arquitectura que sastifaga los requerimientos definidos por los usuarios del sistema, además de ser robusta, confiable, y extensible para futuros desarrollos. Las herramientas de desarrollo de la aplicación serán de libre distribución o en su defecto regidas por licencia académica Viabilidad de la construcción del sistema. De acuerdo al conocimiento y estudios realizados previamente se determina que el proyecto es viable bajo los parámetros establecidos para el cumplimiento de las perspectivas expuestas por los stakeholders Riesgos y operación del sistema. Los riesgos a los cuales se podrían ver enfrentados los usuarios son: Fallas en la red de comunicación. Fallas de disponibilidad del servicio por parte del servidor. Los riesgos a los cuales se podrían ver enfrentados los desarrolladores son Aparición de posibles fallas de las herramientas de libre distribución puesto que no en la mayoría de los casos no existe soporte directo para la solución de inconvenientes Instalación y evolución del sistema. La instalación del sistema se hará en un servidor y las peticiones de los usuarios se harán vía http sin que éstos requieran de una instalación previa en sus terminales de acceso Posibles evoluciones de la arquitectura propuesta para proyectos posteriores. Las siguientes propuestas han surgido a lo largo del proyecto y aunque no están contempladas dentro del alcance del proyecto quedarán propuestas para futuros desarrollos 1. Agregar un componente para permitir la prestación de servicios a través de Web services, utilizando herramientas como AXIS y basados en la arquitectura propuesta; con lo cual sistemas externos podrían consumir y alimentar la biblioteca a través del intercambio de documentos XML basados en el estándar utilizado en la definición de los componentes. 2. Cambiar la Base de datos relacional por una nativa en XML; con lo cual se podrá lograr un diseño de la base de datos más compacto.

6 3. Agregar nuevas funcionalidades de lógica de negocio como actualizar la descripción de los componentes, funcionalidades de administración sobre el repositorio, acceso de forma directa a los componentes almacenados en la base de datos, funciones de estadísticas de consulta. 4. Agregar una nueva funcionalidad para permitir que los componentes puedan ser ejecutados de forma remota, es decir prestar los servicios del componente sin necesidad de descargarlo desde el lado del cliente. 5. Definición de puntos de vista por stakeholder. Nombre: Usuarios Propósito: Consultas de componentes por funcionalidad, tipo de arquitectura y lenguaje de programación. Cuando será usado: Cuando este en producción el sistema. Stakeholders: usuarios y proveedores. Diagrama asociado: Diagrama de despliegue. Nombre: Desarrolladores Propósito: Definir arquitectura, satisfacer las necesidades de los usuarios y proveedores del sistema. Cuando será usado: Durante la fase de análisis e implementación del sistema. Stakeholders: Desarrolladores. Diagrama asociado: Diagrama de despliegue. Relación a otras vistas: Vista de usuario. 6. Definición de vistas Consistencia entre los puntos de vista. Los puntos de vista son consistentes en cuanto a la viabilidad del desarrollo del proyecto puesto que básicamente se trata de satisfacer las necesidades de los usuarios y proveedores, por lo cual la vista de los desarrolladores se basa específicamente en los requerimientos predefinidos anteriormente Vista desarrolladores del sistema.

7 La vista lógica del sistema está comprendida en 3 paquetes principales: Interfaz de Usuario, Lógica de Negocio y Almacenamiento de información. La Interfaz de Usuario contiene clases para cada una de las formas con las cuales los usuarios se comuniquen con el sistema. La lógica del Negocio contiene las clases controladoras para el manejo de la lógica del negocio su función principal será la de recibir las peticiones de la capa Web en cuanto a las consultas de componentes y presentar los resultados a la capa Web, Almacenamiento de Información contiene las tablas que representan los metadatos de los componentes descritos en el estándar.

8 Web Vista Usuario Interfaz Negocio Servlet Controlador -JNDI Contenedor EJB Modelo -JNDI EJB Sesion -JNDI EJB Entity DAO -JDBC Datos -JDBC 6.3. Vista usuarios y proveedores

9 Usuario o Proveedor Browser Http Servidor Repositorio JDBC 7. Modelo de arquitectura La arquitectura que permite cumplir con las principales perspectivas tanto de usuarios, proveedores y desarrolladores es la mostrada en la gráfica, la cual corresponde a J2EE, a continuación definiremos en mayor detalle cada una de las capas que componen esta arquitectura. Descripción del diagrama general de arquitectura: Capa de presentación: Es la encargada de interactuar con el usuario final del repositorio, básicamente serán JSP s bajo un browser.

10 Web Server: El contenedor web será Tomcat el cuál se encargará de procesar los JSP s y Servlet s. Application Server: El contenedor será JBoss el cual se encargará de procesar Los EJB s que definen la lógica de negocio y el datasource mediante el cual se tendrá acceso a la Base de Datos. Datos: Se encarga de la persistencia de los datos que describen los componentes y los usuarios que acceden a publicar a la biblioteca. Las Bases de datos relacionales más probables para la implementación serán Oracle9i o SQL Server 2000.