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. 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.

1.2. 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 1471 2000, IEEE

Recommended Practice for Architectural Description of
Software-Intensive Systems.
 Pressman, Roger S, Ingeniería de software un enfoque practico, Mc Graw Hill,
2002

2. 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 2000.

 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

Los stakeholders identificados para el repositorio de metadatos de componentes de
software son: usuarios del sistema, proveedores y desarrolladores del sistema.

4.1. 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.

4.1.1.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.

4.2. Proveedores.

Serán los encargados de ingresar la descripción de componentes que se deseen

encontrar a través de la biblioteca.

4.2.1.Perspectiva frente al sistema

 Facilidad de ingreso de información básica del componte a través de la

interfaz Web.

4.3. 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.

4.3.1.Perspectiva frente al sistema.

  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.
4.4. 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.

4.5. 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.

4.6. 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.

4.6.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. 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.
 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.

6.1. 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.

6.2. Vista desarrolladores del sistema.

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.
Web

*
Vista

*
Interfaz
*
Usuario

Negocio *

Controlador
Servlet

* -JNDI

Contenedor EJB
Modelo -JNDI

-JNDI *
DAO
EJB Sesion EJB Entity * *

** * -JDBC

Datos
*
-JDBC

6.3. Vista usuarios y proveedores

 Usuario o Proveedor
Servidor
Http
Browser
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.
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.