You are on page 1of 10

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

1. Introducción. 1.1. Propósito. 1.2. Alcance. 1.3. Definiciones. 1.4 Contexto. 1.5. Referencia. 2. Objetivos y restricciones de la arquitectura. 3. Arquitectura y ventajas. 4. Identificación de StakeHolders y Objetivos. 4.1 Usuarios del sistema. 4.1.1 Perspectiva frente al sistema. 4.2 Desarrolladores del Sistema. 4.2.1 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. 4.6.1 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.

1. La agrupación de vistas definen la arquitectura del sistema.1.2.5 Referencias IEEE Std 1471 2000. Alcance El alcance del documento es dar una visión global de la arquitectura del repositorio de metadatos de componentes. Propósito Este documento pretende dar a conocer la estructura de la arquitectura del repositorio de metadatos de componentes de software. enfocándonos principalmente en construir un sistema robusto. . para lo cual utilizaremos diferentes vistas de los stakeholders que puedan mostrar los aspectos más importantes del sistema. así como también permitir ser extensible a futuros desarrollos. 1. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.3 Definiciones Objetivos: Son los intereses particulares de cada unos de los stakeholders frente al Sistema. definidas con anterioridad en el documento de requerimientos.1.4 Contexto Se analizará la arquitectura desde el punto de vista de los usuarios y los desarrolladores. 1. con el fin de cumplir las diferentes funcionalidades del 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. 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. Introducción 1. 1.

El sistema manejará la persistencia de datos a través de una base de datos relacional Oracle 9i o SQL Server 2000. Soportar conexiones concurrentes. 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. Roger S. Arquitectura y ventajas. 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.    Acceder a la aplicación a través de un Browser. Ingeniería de software un enfoque practico. Identificación de StakeHolders y Objetivos .   3. Mc Graw Hill. 4. El sistema poseerá seguridad para los datos que se almacenan en el mismo. 2002 2. Permitir desarrollos posteriores en cuanto a la transaccionalidad de documentos XML.Pressman. acceso a componentes de forma directa o link al proveedor principal. Esta será ejecutada a través de un navegador de Internet. Los requerimientos que se establecieron en el documento de Especificación de requerimientos deben ser tenidos en cuenta. incluyendo solicitudes a la base de datos en cualquier instante de tiempo. 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.

2. 4. 4. Las consultas deberán ser sencillas y permitir delimitarlas de acuerdo a las principales características de los componentes tales como funcionalidad. Serán los encargados de ingresar la descripción de componentes que se deseen encontrar a través de la biblioteca. La interfaz de comunicación con el sistema debería ser sencilla en cuanto al acceso a las funcionalidades de consulta.3.1. Somos los encargados de analizar los requerimientos definidos por el sector de las PyMEs seleccionado por el estudio previo. Desarrolladores del sistema Los desarrolladores del sistema somos Rodrigo Fonseca y Dawid Junnco.3.  Los usuarios del sistema buscan un acceso vía Web al repositorio con el fin de consultar los componentes de acuerdo a su funcionalidad.1.Perspectiva frente al sistema.1. 4.Perspectiva frente al sistema. 4. .2. tipo de arquitectura y lenguaje de programación (De acuerdo a los resultados de las encuestas realizadas).   4.1. 4.Perspectiva frente al sistema  Facilidad de ingreso de información básica del componte a través de la interfaz Web.1. Proveedores. 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.Los stakeholders identificados para el repositorio de metadatos de componentes de software son: usuarios del sistema. tipo de arquitectura y lenguaje de programación.

 Fallas de disponibilidad del servicio por parte del servidor. 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. utilizando herramientas como AXIS y basados en la arquitectura propuesta. 2. con lo cual se podrá lograr un diseño de la base de datos más compacto. además de ser robusta. Instalación y evolución del sistema.6. Agregar un componente para permitir la prestación de servicios a través de Web services.5. 4. Cambiar la Base de datos relacional por una nativa en XML.4. . Riesgos y operación del sistema.6. 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.  Las herramientas de desarrollo de la aplicación serán de libre distribución o en su defecto regidas por licencia académica.Nuestro interés se centra en definir una arquitectura que sastifaga los requerimientos definidos por los usuarios del sistema. 4. 4. Viabilidad de la construcción del sistema.  4. 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. 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.1 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. y extensible para futuros desarrollos. confiable. Los riesgos a los cuales se podrían ver enfrentados los usuarios son:  Fallas en la red de comunicación.

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

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.La vista lógica del sistema está comprendida en 3 paquetes principales: Interfaz de Usuario. Almacenamiento de Información contiene las tablas que representan los metadatos de los componentes descritos en el estándar.

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

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

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. 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.Web Server: El contenedor web será Tomcat el cuál se encargará de procesar los JSP’s y Servlet’s.