ANÁLISIS DEL DESEMPEÑO DE UN ENFOQUE ARQUITECTÓNICO DATA WAREHOUSE DE INTEGRACIÓN DE SISTEMAS RESUMEN

Transcripción

1 ANÁLISIS DEL DESEMPEÑO DE UN ENFOQUE ARQUITECTÓNICO DATA WAREHOUSE DE INTEGRACIÓN DE SISTEMAS Luis E. Mendoza; María Pérez Laboratorio de Investigación en Sistemas de Información (LISI). Departamento de Procesos y Sistemas, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas - Venezuela. Telef.: +58 (212) / 3328 / 3314 / Fax: +58 (212) / 3303 {lmendoza, movalles}@usb.ve Mariela Curiel Grupo de Sistemas Paralelos y Distribuidos Dpto. de Computación y Tecnología de la Información, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas - Venezuela. Telef.: +58 (212) / 3241 / Fax: +58 (212) mcuriel@usb.ve RESUMEN La integración de sistemas de software está afectada por: la demanda de operaciones en tiempo real, el manejo de la información oportuna y la orientación hacia el cliente; todas relacionadas con el desempeño. Esta investigación presenta el análisis de un Enfoque Arquitectónico Warehouse de integración de sistemas que busca propiciar el atributo de calidad de desempeño. Para ello se realizó el análisis de un Enfoque Arquitectónico Warehouse y, se identificó y estudio un conjunto de puntos de atención para el arquitecto de software, vinculados directamente con el desempeño, mediante el desarrollo de un modelo de simulación. Aunque esta investigación está limitada estrictamente al Enfoque Arquitectónico Warehouse de integración de sistemas, el análisis puede ser extrapolado a cualquier otro enfoque arquitectónico de integración de sistemas que busque propiciar el desempeño como atributo de calidad. Palabras claves: Arquitectura de Software, Warehouse, Desempeño, Métricas de software, Simulación. 1. INTRODUCCIÓN A lo largo de la historia de Ingeniería del Software, el desempeño ha sido un factor determinante en la arquitectura de sistemas y está frecuentemente comprometido con el logro de la calidad de éstos [1]. En el contexto actual de competitividad de los negocios, para alcanzar los objetivos de servicio los sistemas deben tener un desempeño mayor al presentado en el pasado. El poder alcanzar un desempeño aceptable no es una opción, es una base fundamental de la calidad de las aplicaciones [6]. Los mayores riesgos que sufren los negocios al ignorar los aspectos de desempeño durante la fase de diseño de los sistemas, son que las degradaciones o cuellos de botella no surgirán sino hasta el momento en que el sistema es implantado y los volúmenes de datos y transacciones comienzan a crecer hacia los niveles esperados de producción. Comúnmente se observa el hecho de que existe la preferencia en el proceso de desarrollo de sistemas de construir primero y entonar luego [6]. El enfoque contrario al anterior es estudiado por la Ingeniería del Desempeño del Software (Software Performance Engineering o SPE), la cual, según Loosley [6], es definida por Smith como un método de construcción de sistemas para lograr los objetivos de desempeño, teniéndolos en cuenta desde las fases iniciales del desarrollo. Sobre la base de los hechos descritos anteriormente, en esta investigación se presenta y analiza un Enfoque Arquitectónico (EA) Warehouse de integración de sistemas que busca propiciar el atributo de calidad de desempeño. Además, se presentan un conjunto de puntos de atención para el arquitecto, los cuales están vinculados de manera directa con el desempeño. Tanto el EA como los puntos de atención son evaluados mediante el desarrollo de un modelo de simulación. En la siguiente sección se tratarán los conceptos asociados a integración, arquitecturas, desempeño y atributos de calidad, para posteriormente proponer el EA. Seguidamente, se describen los puntos de atención para el arquitecto de software, para pasar a describir el modelo de simulación que permite analizar el desempeño del EA. Finalmente, se analizan las predicciones del modelo, así como los puntos de atención para el arquitecto de software, y se enumeran

2 las conclusiones del artículo. 2. ANTECEDENTES 2.1. Integración La integración del negocio, así como los negocios beneficiados de los procesos de reingeniería, requiere de procesos dinámicos y del soporte de Sistemas de Información (SI) integrados capaces de combinar la información de muchas fuentes. En este sentido, según Markus [8], la integración de los SI se refiere a la creación de uniones más fuertes entre los diferentes SI y sus bases de datos. De igual modo que hay diversos tipos de integración, existen diferentes enfoques de integración de los sistemas. Tradicionalmente, una manera de integrar los sistemas consiste en la creación de un software que sirva de puente entre los SI, para que los datos de un sistema sean transferidos al otro de alguna manera [8]. Pero cuando existen muchos sistemas esta estrategia no es la ideal ya que es necesaria la creación de muchas de estas aplicaciones (interfaces) y esto puede incurrir en un excesivo gasto de dinero y de tiempo para la organización, sobre todo en lo que se refiere al mantenimiento de los sistemas Arquitecturas, Desempeño y Calidad de Software La arquitectura de software permite evaluaciones tempranas y un diseño enfocado hacia los atributos de calidad de un sistema de software [3]. Así mismo, la arquitectura a definir juega un papel muy importante en el resultado final entregado a los usuarios, ya que dependiendo de su definición y diseño, no sólo el desempeño del sistema, sino los objetivos planteados en el negocio, pueden ser llevados a un fin satisfactorio. De igual manera la arquitectura es un factor importante en las respuestas de los negocios, ya que su definición afecta el resultado final para los procesos de integración de sistemas. Según Bass et al. [1], el desempeño es un atributo de calidad del tipo observable vía ejecución, tal como lo muestra la Tabla 1. Los atributos de calidad observables vía ejecución deben responder a las siguientes preguntas: Cuán bien el sistema satisface los requerimientos de comportamiento durante la ejecución?, Provee los resultados requeridos?, Funciona el sistema de manera adecuada cuando se conecta a otros sistemas? [1]. Tabla 1. Atributos de calidad observables vía ejecución. Adaptado de Bass et al. [1]. Atributo Descripción Se refiere a la capacidad de respuesta del sistema -el tiempo requerido para responder a los estímulos (eventos) o el número de eventos procesados en algún intervalo de Desempeño tiempo. El desempeño es a menudo una función de cuánta comunicación y interacción hay entre los componentes del sistema -claramente es un problema arquitectónico. Es una medida de la habilidad del sistema de resistirse a intentos no autorizados de uso, Seguridad así como el rechazo a prestar servicio, mientras sigue proporcionando sus servicios para legitimar a los usuarios. Disponibilidad Medidas de la proporción de tiempo que el sistema es levantado y puesto en marcha. Funcionalidad Es la habilidad del sistema de hacer el trabajo para el que fue concebido. Usabilidad O facilidad de uso del sistema Debido a que la comunicación usualmente toma más tiempo que la computación, el desempeño es también medido como una función de cuánta comunicación e interacción existe entre los componentes de un sistema (lo cual es claramente un aspecto de arquitectura). Esto es especialmente cierto si los componentes residen en diferentes elementos computacionales, como en el caso de un sistema distribuido. Sin embargo, es todavía cierto cuando todos los componentes ocupan el mismo procesador. La cantidad de interacción por invocación de sub-rutinas, sincronización de procesos u otros mecanismos de comunicación todavía tiende a ser una guía del desempeño, lo cual hace que sea extensamente una función de la arquitectura [1]. El Desempeño depende del volumen y la complejidad de la comunicación y la coordinación entre los componentes de la arquitectura, especialmente si los componentes son procesos distribuidos físicamente [1]. 3. ENFOQUE ARQUITECTÓNICO DATA WAREHOUSE El término Enfoque es utilizado comúnmente debido a que no todos los arquitectos están familiarizados con el lenguaje de estilos arquitectónicos y, tal vez no podrían enumerar un conjunto de estilos usados en una arquitectura,

3 pero a su vez, cada arquitecto toma decisiones arquitectónicas y a ese conjunto se le llama Enfoque. Los mismos pueden ser certeramente determinados por cualquier arquitecto consciente [5]. Generalmente, cuando una organización tiene muchos sistemas necesita un Enfoque sólido a la integración. Según Markus [8] hay tres Enfoques para la integración de los sistemas a considerar: Warehouse, Enterprise Resource Planning (ERP) y Enterprise Application Integration (EAI). Estos tres Enfoques Arquitectónicos (EA) están en continua evolución, al punto que según O Brien [10] el EA esperado para una organización integrada es la convivencia de los tres; sin embargo, el EA Warehouse es el que refleja madurez en su composición y uso, además los Warehouses son reconocidos como los tipos de sistemas de mayor valor real para soportar muchos de los tipos de decisiones que son tomadas en la mayoría de las organizaciones [7]. Con este Enfoque las compañías dejan sus sistemas trabajando en tiempo real con las bases de datos necesarias para su funcionamiento y después los datos son integrados y cargados en el Warehouse donde podrán ser analizados y estudiados mediante herramientas de análisis en común. Este Enfoque tiene la desventaja de que integra y centraliza los datos de la compañía sin tomar en cuenta los procesos de ésta [8]. El EA Warehouse aquí analizado se observa en la Figura 1, identificándose los siguientes estilos arquitectónicos: Pipe and Filter Objetos Web Operacional Transaccional Externo Selección Extracción Integración Transformación Mantenimiento Preparación Meta Warehouse Mart Mart Mart A P I DSS OLAP Reportes Mining Warehouse API Presentación Figura 1. EA analizado y estilos arquitectónicos identificados. a) Estilo de capas: presente en la interacción entre las siguientes capas: Warehouse: Repositorio que contiene la información procesada de las diferentes áreas del negocio en un ambiente integrado. Aplication Program Interface (API): Se encarga del manejo de la comunicación entre la capa de Presentación y la capa de Warehouse. Presentación: Componentes que permiten la interacción con el usuario final, permitiéndole navegar a través de la información de diferentes áreas de negocio en un ambiente único, integrado y flexible. Dentro de esta capa se identificaron los siguientes componentes: Mining: programas de minería de datos, que permiten realizar extracción de datos para estudios que permitan identificar comportamientos, tendencias e información de predicción a partir de una base de datos accesible desde el Warehouse Reportes: aplicaciones que permiten realizar una consulta predeterminada de los datos del Warehouse Decision Support Systems (DSS): sistemas orientados a apoyar la toma de decisiones de la alta gerencia, a partir de módulos de análisis de datos, pro yecciones y ponderaciones de variables. OnLine Analitical Process (OLAP): aplicaciones que permiten realizar navegación entre los datos del Warehouse o de un Mart específico, para realizar procesos de análisis de datos en línea. Según Bass et al. [1], este estilo favorece, el atributo de calidad de Escalabilidad, castigando el Desempeño y la Integridad Conceptual. b) Estilo Pipe and Filter: presente en la interacción entre el Warehouse y los sistemas de datos operacionales,

4 corresponde a los procesos ejecutados mediante un esquema de agenda o batch. Estos procesos son de Selección, Extracción, Integración, Transformación, Mantenimiento y Preparación de los datos desde los sistemas operacionales hacia el Warehouse. Este estilo favorece, según Bass et al. [1], los atributos de calidad de Reuso y Modificabilidad, a su vez castiga el Desempeño. c) Estilo Orientado a Objetos: presente en la capa API, ya que los componentes de software de esta capa se desarrollarán a través de módulos programados bajo orientación a objetos. Este estilo favorece, según Bass et al. [1], los atributos de calidad de Modificabilidad, Reuso y Escalabilidad, de igual modo se deben realizar ajustes para favorecer el Desempeño. d) Estilo Basado en Web: presente en la capa de Presentación, integrando este componente a la intranet / extranet de la organización. La Presentación se accede a través de un browser, por lo que se hace necesaria la integración de esta capa con la tecnología web disponible en la organización, bien sea a través de los servidores existentes, o creando un nuevo sitio en la intranet / extranet organizacional. Este estilo favorece, según Bass et al. [1], los atributos de calidad de Reuso, Usabilidad y Portabilidad, castigando el Desempeño y la Integridad Conceptual Como se puede observar, los estilos que componen este EA no propician el atributo de calidad de desempeño, sino que favorecen otros atributos. Es por esto que el EA analizado debe ser complementado con la identificación y el estudio de un conjunto de Puntos de Atención (PA), que el arquitecto debe contemplar para poder propiciar el atributo de calidad de desempeño del sistema. Estos PA son descritos en la próxima sección. 4. PUNTOS DE ATENCIÓN Dado que la meta de este trabajo de investigación es analizar el EA Warehouse de integración de sistemas que favorezca el atributo de calidad de Desempeño, los PA son aspectos arquitectónicos que afectan el desempeño del sistema que implemente el EA de una manera o de otra. A continuación se describen estos PA: PA 1) En este EA, cada una de las capas puede estar ejecutándose en uno o varios servidores. PA 2) En el caso de los servidores, estos tienen una influencia directa en el desempeño de los sistemas desarrollados bajo la arquitectura propuesta, por lo que se debe reforzar la capacidad de procesamiento de los mismos; es decir, mayor capacidad en disco, memoria y procesador. PA 3) Para la capa de Warehouse se recomienda el uso de tecnologías de servidores de clusters, donde cada nodo consiste de uno o más CPUs y memoria dedicada asociada, aprovechando las ventajas que ofrecen los esquemas de multiprocesamiento paralelo masivo para el desempeño También es recomendable disponer de múltiples discos para disminuir el tiempo de consulta. PA 4) Para la capa de API se recomienda tomar en cuenta la capacidad de múltiple procesamiento de las peticiones de consulta. PA 5) Para la capa de Presentación se puede tomar en cuenta el uso de esquemas de tolerancias a fallas y balanceo de cargas, con el objetivo de manejar de manera más eficiente la presentación al usuario. PA 6) De igual manera, la capa de Presentación debe brindar páginas Web livianas, fáciles de acceder e intuitivas, debido a que esta es la interacción directa con el usuario, y una degradación en el desempeño de la capa de presentación puede generar un trauma en la percepción sobre la arquitectura global. Aunque los PA son aspectos que afectan de alguna forma el desempeño del sistema que implementa el EA, es necesario estudiar, analizar y demostrar cuáles de estos puntos tienen una mayor influencia. Esto es normalmente estudiado por la SPE a través de un modelo de rendimiento. El modelo permite, a un costo muy bajo, evaluar diversas alternativas para la implantación de la arquitectura, a fin de descubrir aquellas que realmente favorecen el atributo de calidad de desempeño. En la próxima sección se describirá el modelo a desarrolla do. 5. MODELO DE DESEMPEÑO DE LA ARQUITECTURA DE INTEGRACIÓN Los métodos para evaluar el desempeño de los sistemas informáticos se pueden dividir en dos principales áreas conocidas como: evaluación basada en medidas y la evaluación basada en modelos. Las medidas son sólo factibles cuando existe el sistema propuesto o alguno similar. Si se trata de un nuevo sistema o de la definición de componentes de hardware o software de uno ya existente, los modelos son la única alternativa posible. Esto justifica el uso de un modelo para evaluar la propuesta de una arquitectura de integración.

5 Los modelos se fundamentan, en general, en la teoría de colas, pudiéndose considerar las colas o bien de forma individual o bien unidas formando redes abiertas o cerradas. Su tratamiento se puede realizar mediante los métodos analíticos que proporcionan la teoría de colas y de redes de colas, o por medio de la simulación. Una red de colas es un conjunto de centros de servicio y clientes. Los centros de servicio representan los recursos del sistema (dispositivos de E/S, CPU, etc) y los clientes son los usuarios (procesos, transacciones, mensajes, etc). La implementación de la arquitectura de integración warehouse se representó con un modelo de redes de colas abierto el cual se resolvió usando la técnica de simulación. Los sistemas abiertos corresponden a aquellos donde no hay ningún tipo de restricción en cuanto al número de clientes. Estos llegan al sistema de una fuente exterior, pasan a través de varios de los recursos, y al cabo de un tiempo lo abandonan [9]. El modelo se desarrolló usando la herramienta ARENA (desarrollado por System Modeling Corporation sobre la base del estudio realizado por Becerra [2]. Para construir un modelo es necesario especificar los parámetros de entrada y los centros de servicio. El modelo será capaz de predecir el valor de ciertas métricas (tiempos de respuesta, utilizaciones, throughputs) a partir de dichos parámetros de entrada. Los próximos párrafos explican todos los elementos importantes en la construcción del modelo de desempeño. 5.1 Componentes del modelo En la Figura 2, se presenta el EA analizado, el óvalo resalta los elementos que formarán parte del modelo: El Warehouse, el API, y los elementos de la capa de presentación. Los Sistemas de Datos Operacionales no formarán parte del modelo porque no afectan de forma determinante el desempeño. La razón de ello es que los programas de Carga de Datos, desde los Sistemas de Datos Operacionales hacia el Warehouse, normalmente se ejecutan fuera del horario regular de servicio de las aplicaciones y los componentes del EA objeto de análisis. Selección Componentes a simular Extracción Integración Transformación Mantenimiento Preparación Reglas del negocio A P I Web Server Sistemas de Datos Operacionales Warehouse API Figura 2. Elementos de análisis para la simulación. Presentación En una primera versión del modelo los componentes de cada capa residieron en un único servidor con ciertas características que se mencionarán en la sección 6.2; tales características se consideraron idóneas para dichos servidores. Los servidores serán los centros de servicio del modelo de colas y la forma como se modelaron se describe a continuación a) Warehouse: Este servidor se representa utilizando el modelo de servidor central, introducido por Buzen [4], el cual es el esquema básico de redes de colas usado para estudiar las prestaciones de un sistema informático. En este modelo, el CPU es el centro de servicio central que coordina las visitas de los clientes a los dispositivos de Entrada/Salida (E/S). Una vez que los clientes reciben el servicio de los dispositivos de E/S, retornan al CPU donde permanecen hasta una nueva operación de E/S, o hasta el fin de su ejecución. El CPU maneja las peticiones de la capa superior y las envía a los discos quienes se encargan del almacenamiento y de responder dichas peticiones. Para simular la existencia de un arreglo de discos, éstos se modelarán también como un centro de colas de procesamiento mú ltiple. b) API: Se simulará como un servidor de peticiones, con un esquema de manejo de tráfico de información entre el Warehouse y el servidor de presentación. Para este caso no se requiere modelar los discos, porque es un servidor orientado más al procesamiento que al almacenamiento.

6 c) Presentación: Se simulará un servidor de envío de peticiones a la capa API y de manejo de respuestas hacia el cliente. Será en este servidor donde se conectarán los clientes. En este caso tampoco se requiere modelar los discos, porque este es un servidor más orientado al procesamiento que al almacenamiento. Los componentes del modelo según la interfaz de la herramienta ARENA se pueden observar en la Figura Entradas del modelo Figura 3. Modelo de colas propuesto, según la herramienta ARENA. Las entradas de un modelo son los parámetros de hardware, del sistema operativo, y middleware y la carga de trabajo. En esta investigación comenzamos con un modelo muy simple donde se omiten los parámetros correspondientes a sistema operativo y middleware, los parámetros del hardware y la carga de trabajo se describen a continuación. a) Parámetros de Hardware: los parámetros para cada uno de los centros de servicio son mostrados en la Tabla 2. Tabla 2. Parámetros de Hardware del modelo. Parámetro Servidor Warehouse Servidor API Servidor Presentación Número de procesadores Velocidad de cada procesador 800 Mhz 733 Mhz 733 Mhz Cantidad de discos 20 b) Carga de trabajo: para calibrar el modelo se utilizó una transacción típica de este tipo de arquitecturas [1]. Las características de esta transacción, medidas en una plataforma de hardware como la antes descrita, se presentan en la Tabla 3. Tiempo medio de servicio en el Warehouse Tiempo medio de servicio en el servidor API Tabla 3. Carga de trabajo del modelo. Tiempo medio de servicio en el servidor de presentación Número de operaciones de Entrada/Salida Tiempo medio entre llegadas 0,012 s 0,160 s 0,26 s 70 3 s La transacción se modeló como dos clases de cliente que se denominarán: petición y respuesta. La petición es el query que introduce el cliente y que va desde la capa presentación al Warehouse. La respuesta, como su nombre lo indica, se compone de los datos que vienen desde el Warehouse en respuesta a la solicitud del

7 cliente. Por ahora estas dos clases de cliente sólo se diferencian por el orden en que recorren los centros de servicio del modelo. Aunque el tiempo de servicio en cada servidor de estas dos clases de cliente no tiene porque ser similar, por ahora se trabajo con esta suposición. Posteriormente, con herramientas y técnicas de monitoreo más precisas, se diferenciarán las demandas de servicio de las dos clases de cliente. El flujo de los clientes a través de los centros de servicio del modelo se describe a continuación y puede observarse en la Figura 3: 1) El servidor de Presentación atiende tanto las peticiones de los clientes como las respuestas a dichas peticiones. Si la entrada de este centro de servicio es una petición, se envía al servidor API. Si la entrada es una respuesta se muestran los resultados al cliente. 2) En el API sucede algo similar: se reciben peticiones de la capa de Presentación y las respuestas que vienen del servidor del Warehouse. Si se reciben peticiones, se envían al Warehouse. Si es una respuesta a una petición introducida anteriormente, se envía al servidor de Presentación. 3) Al Warehouse llegan peticiones y salen respuestas. Una petición viaja entre el procesador y los discos tantas veces como sea necesario de acuerdo al número de operaciones de E/S. Una vez culminadas estas operaciones de E/S el Warehouse envía una respuesta a la capa API Salidas del modelo Las métricas más importantes que se condideran en un sistema con interfaz Web son el tiempo de respuesta, la productividad (throughput), la disponibilidad y el costo. De ellas, sólo el tiempo de respuesta y la productividad están relacionadas con el atributo de calidad de Desempeño, donde el tiempo de respuesta es una métrica de interés para el usuario y la productividad es la métrica de interés para los administradores del sistema [9]. De igual modo, para evaluar el desempeño se consideró otra métrica de interés para los administradores de sistemas como lo fue la utilización de recursos. En la Tabla 4 se detalla la especificación del atributo desempeño, con sus métricas correspondientes. Tabla 4. Especificación del atributo Desempeño. Atributo Métrica Unidad Regla de Medición Tiempo transcurrido desde Tiempo completo Segundos el inicio hasta el retorno de respuesta completo de la transacción Utilización de los Porcentaje de uso CPU y de Desempeño % recursos los discos Throughtput 6. PREDICCIONES DEL MODELO Transacciones/ Segundos # Transacciones procesadas en el sistema por unidad de tiempo Una vez parametrizado el modelo éste se ejecutó para observar el valor de sus predicciones. La Tabla 5 muestra el valor de las métricas de interés. Tabla 5. Medición del atributo Desempeño en el modelo de simulación. Métrica Modelo de simulación Tiempo de respuesta 4,3 s Utilización del servidor Presentación 17,2 % Utilización del servidor API 10,65 % Utilizacion del CPU del servidor Warehouse 69,9 % Utilizacion del disco Warehouse 38,5 % Throughput del sistema 0,3 transacciones/s El tiempo de respuesta promedio estuvo en un orden aceptable; sistemas reales ejecutando este tipo de transacción presentan valores muy cercanos a 4 s [1] Se puede observar también que las utilizaciones para los servidores de Presentación y API fueron bastante bajas, lo que sugiere que pudieran utilizarse servidores con una menor capacidad de procesamiento. Como era de esperarse, la mayor utilización lo tuvieron los dispositivos del Warehouse ya

8 que son los encargados de manejar las peticiones, procesar los datos y generar las respuestas. 7. ANÁLISIS DE LOS PUNTOS DE ATENCIÓN DEL ARQUITECTO Al modelo desarrollado se le realizaron ciertas modificaciones con el objeto de observar de validar algunos de los PA del arquitecto, relacionados con el hardware. Las modificaciones realizadas se presentan a continuación: a) Se redujeron a un sólo CPU los servidores de Presentación y API (cambio relacionado al PA 2). b) Se redujo a un sólo CPU el servidor del Warehouse (cambio relacionado al PA 2). c) Se redujo el número de Discos del Warehouse a un solo disco (cambio relacionado al PA 2). d) Se redujo el número de Discos del Warehouse a un solo arreglo de cinco (5) discos (cambio relacionado al PA 2). e) Se redujo el esquema del Warehouse a un solo servidor, reduciendo el disco y el CPU a una sola unidad de procesamiento (cambio relacionado a los PA 2 y 3). A continuación observaremos cómo afectaron estos cambios a las métricas de interés Tiempo de respuesta promedio En la Tabla 5 se detallan los resultados del tiempo de respuesta promedio, en segundos. Tabla 5. Resultados del Tiempo de respuesta. Modelo Modificaciones Métrica original (a) (b) (c) (d) (e) Tiempo de respuesta promedio Los cambios que más incid ieron en el desempeño, tal y como lo percibe el usuario, son aquellos relacionados con el hardware del Warehouse, el núcleo de la Arquitectura. Las predicciones del modelo sugieren que no hay que escatimar en los recursos destinados al Warehouse, especialmente en las capacidades del procesador, si se quiere obtener un tiempo de respuesta de un nivel aceptable. No obstante, los procesadores en los servidores API y Presentación pudieran ser más modestos, ya que el tiempo que la transacción pasa en ellos es sólo un pequeño porcentaje en relación al tiempo total Uso de los recursos En la Tabla 6 se detallan los resultados del Uso de recursos. Tabla 6. Resultados del Uso de Recursos. Métrica Modelo Modificaciones original (a) (b) (c) (d) (e) Promedio de uso del servidor Presentación (%) Promedio de uso del servidor API (%) Promedio de uso del CPU del servidor Warehouse (%) Promedio de uso del dis - co Warehouse (%) Con las modificaciones realizadas al modelo las utilizaciones de los dispositivos no se afectan en forma determinante. Hay que cuidar no obstante, el procesador del servidor del Warehouse que es el que presenta los niveles más altos y podría ser un cuello de botella con una mayor carga de trabajo. Para la carga actual los procesadores de la capa de presentación y API tienen capacidad suficiente, se pudiera incluso pensar en dispositivos mas modestos y económicos para estas capas, si la carga de trabajo es similar a la representada en el modelo. Lo mismo sucede en el caso del disco del Warehouse.

9 Con base en estos resultados el PA 2 se debe modificar para especificar que el servidor más poderoso a nivel de hardware debe ser el que albergue la capa del Warehouse; se debe colocar especial atención a las capacidades de procesamiento del mismo. 8. CONCLUSIONES La simulación de una arquitectura de software permite evaluaciones tempranas y un diseño enfocado hacia los atributos de calidad de un sistema de software. En esta investigación, se analizó tanto un Enfoque Arquitectónico Warehouse de integración de sistemas para estudiar el atributo de calidad de desempeño, como su modelo de desempeño para su simulación. Los mayores riesgos que sufren los negocios al ignorar los aspectos de desempeño durante la fase de diseño de los sistemas, son que las degradaciones o cuellos de botella no surgirán sino hasta el momento en que el sistema es implantado y los volúmenes de datos y transacciones comienzan a crecer hacia los niveles esperados de producción. La evaluación del desempeño a través del modelo de simulación, permitió comprobar que si no se toman en cuenta los puntos de a tención al momento de implantar el Warehouse, se puede afectar negativamente el desempeño de éste. Según el análisis de la simulación del modelo de desempeño, no se debe ahorrar costos en los recursos dedicados al Warehouse, sobre todo en las capacidades del procesador. El modelo de la simulación analizado a través de esta investigación puede modificarse fácilmente para estudiar el desempeño de la implantación de cualquier Enfoque Arquitectónico Warehouse de integración de sistemas, dado que es un modelo de redes de colas abierto. En este sentido, la posibilidad de "jugar" con los diferentes parámetros del modelo, hacen que ésta sea una herramienta útil para analizar los puntos de atención considerados importantes por el arquitecto de softwa re, permitiéndole ser más acertado en sus decisiones. AGRADECIMIENTOS Esta investigación fue financiada por el Fondo Nacional de Ciencia, Tecnología e Innovación (FONACIT) de la República Bolivariana de Venezuela, a través del proyecto S Los autores desean dar las gracias a C. Becerra por su valiosa colaboración en la culminación de esta investigación. REFERENCIAS 1. Bass, L., Clements, P. and Kazman, R. Software Architecture in Practice. Second edition, SEI Series in Software Engineering, Addison Wesley, Becerra, C. Propuesta de una Arquitectura de Integración de Sistemas que propicia el Atributo de Calidad de Desempeño. Tesis. Universidad Simón Bolívar, Bosch, J. Design & Use of Software Architectures. Addison Wesley, Buzen, J.P. Computational Algorithms for Closed Queuing Network with Exponential Servers, Communications of the ACM, 16(9), 1973, pp Clements, P., Kazman, R. and Klein, M. Evaluating Software Architecture. Methods and Case Studies. SEI Series in Software Engineering, Addison Wesley, Loosley, C. and Douglas, F. High-Performance Client/Server. John Wiley & Sons, Mallach, E. Decision Support and Warehouse Systems. McGraw-Hill/Irwin, Markus, M. Paradigm Shifts E-Business and Business/Systems Integration. Communications of AIS, 4(10), November. 2000, pp Menasce, D., Almeida V., Dowdy, L. Capacity Planning and Performance Modeling: From Mainframes to Client-Server Systems. Prentice Hall, O Brien, J. Introduction to Information Systems. Essentials for the e-business Enterprise. Eleventh Edition, McGraw-Hill/Irwin, 2003.