Un Ambiente de Programacion Distribuido para elCalculo Cientıfico Intensivo

M. Gonzalez1;2

e-mail: mgonzale@asci.frhttp://www.erablis.com/martha

andS. Petiton2;3

e-mail: petiton@lifl.fr, petiton@asci.frhttp://www.lifl.fr/˜petiton

1 Escuela de Computaci´on. Universidad Central de Venezuela. Caracas - Venezuela2 Laboratoire d’Applications Scientifiques du Calcul Intensif (ASCI) CNRS-CPR 9029. Universit´e Paris-Sud. Orsay - France3 Laboratoire d’Informatique Fondamentale de Lille (LIFL). Universit´e des Sciences et Technologies de Lille. Lille - France

Resumen

Este art´ıculo presenta la arquitectura de SPIN un ambiente integrado e interactivo para c´alculo cient´ıfico distribuido, suobjetivo principal es permitir el acceso a recursos computacionales remotos, de una manera sencilla y transparente para losusuarios, a trav´es de una interfaz gr´afica.El proceso de dise˜no y desarrollo del ambiente incorpora diversas t´ecnicas basadasen la nociones de: objetos, multiagentes y arquitectura cliente-servidor. Particularmente se utiliza el enfoque OOSE, basado enla nocion de casos de uso para construir los diferentes modelos de requerimientos y de an´alisis del componente del dominiode la problema. Tambi´en su utiliza el modelo PAC-Amodeus, un modelo multiagentes, para expresar la arquitectura de sistemasgraficos interactivos y el est´andar CORBA, basado en la noci´on de objetos distribuidos, para la definici´on de la arquitecturacliente-servidor.

1 Introducci on

Actualmente existe un gran n´umero de aplicaciones que permiten la resoluci´on de problemas de c´alculo cient´ıfico a granescala. Estos problemas manipulan grandes cantidades de datos, y requieren mas poder de c´alculo y de entrada/salida queel provisto por computadores personales; para resolverlos se ha recurrido al uso de computadores de alto rendimiento y a laimplementaci´on de bibliotecas num´ericas de prop´osito general. Como ejemplo de estas bibliotecas se puede mencionar:BLAS:Basic Linear Algebra Subprograms, un conjunto de programas para operaciones sobre matrices y vectores densos [6].PBLAS,una versi´on de BLAS para arquitecturas paralelas [10].Sparskit, un conjunto de programas para la manipulaci´on de matricesesparcidas [23]. Se han hecho tambi´en algunas proposiciones que intentan incorporar, la tecnolog´ıa objetos en el ´ambitodel calculo cient´ıfico intensivo, algunas de estas propuestas son:LAPACK++: Linear Algebra Package[11], una extensi´on,escrita en C++ de la biblioteca LAPACK, la cual permite resolver sistemas de ecuaciones lineales y calcular valores y vectorespropios.POOMA: Parallel Object-Oriented Methods and Applicationsuna biblioteca de clases escritas en C++ cuyo objetivoes proveer un ambiente para la programaci´on en paralelo, bajo el modelo de paralelismo de datos [4].PETSc: Portable,Extensible Toolkit for Scientific computation, un conjunto de estructuras de datos y rutinas que permiten la resoluci´on deecuaciones diferenciales parciales [5].

Recientemente se est´an desarrollando algunas propuestas que utilizan el lenguajeJavaTM , entre estas se puede mencionar:JAMA un paquete para ´algebra lineal que provee clases para la construcci´on y manipulaci´on de matrices reales y densas [2],Jampack: JAva Matrix PACKageuna colecci´on de clases cooperantes dise˜nadas para realizar c´alculos sobre matrices, Jampacksoporta matrices complejas y posee operaciones para la factorizaci´on de matrices [26]. Sin embargo estas ´ultimas propuestasaun no est´an maduras y tratan de solventar los problemas que presenta el lenguajeJavaTM para el calculo numerico.

Muchas de las bibliotecas mencionadas anteriormente han sido optimizadas s´olo para un cierto n´umero de arquitecturas. Ellasposeen, adem´as ciertas debilidades, como por ejemplo la carencia de un modelo conceptual que las sustente y que permita

manipularlas y modificarlas f´acilmente. Por otra parte hace falta una interfaz usuario que facilite su utilizaci´on y un mecanismoque permita su integraci´on e interoperabilidad. Para poder utilizarlas, es necesario involucrarse en los detalles de programaci´onde las mismas, lo cual requiere un esfuerzo importante por parte de los usuarios, quienes muchas veces no tienen el tiemposuficiente de aprender los detalles de una cierta biblioteca o del lenguaje utilizado para su programaci´on. Tambien existenherramientas como MATLAB [15] que intentan resolver algunas de las dificultades mencionadas anteriormente, pero poseeun conjunto elemental de funcionalidades y s´olo esta disponible sobre un n´umero limitado de plataformas.

Por otro lado, gracias al crecimiento del n´umero de computadores conectados a laInternet, los investigadores est´an con-siderando la posibilidad de explotar la potencia combinada de estos computadores y de la red de interconexi´on para resolverproblemas cada vez m´as complejos e interesantes.

La consideraci´on de todos estos problemas han motivado el surgimiento de proyectos que tienen por objetivo proveer am-bientes de c´alculo distribuido a gran escala. Entre estos se puede mencionarGlobus, un proyecto de investigaci´on multi-institucional que busca lograr la construcci´on de una infraestructura de computaci´on que permita el acceso a recursos com-putacionales, independientemente de la ubicaci´on geografica de los recursos y de los usuarios. Una descripci´on detallada delos componentes y servicios provistos por Globus puede ser vista en [12], [13]. La primera etapa del proyecto consiste endefinir los servicios b´asicos requeridos para construir la infrestructura: seguridad, asignaci´on de recursos, administraci´on derecursos, comunicaciones, etc. Las proximas etapas tienen por objetivo resolver problemas de configuraci´on y optimizacion,asi como extender los servicios hacia servicios de m´as alto nivel.

En esta misma tendencia, se propone el dise˜no y desarrollo deSPIN, un ambiente integrado e interactivo para el acceso arecursos remotos. Estos recursos son:

1. Recursos de c´alculo: super computadores, redes de super computadores, estaciones de trabajo, redes de estaciones detrabajo, redes heterog´eneas, etc.

2. Recursos de datos: bases de datos, directorios, etc.3. Recursos de software: herramientas especializadas para la resoluci´on de problemas y para la visualizaci´on de resultados.

El ambiente provee las siguientes ventajas:

1. Independencia de plataformas. La invocaci´on de las operaciones puede realizarse independientemente del lenguaje deprogramaci´on en el cual est´an implementadas las bibliotecas y del sistema operativo de la m´aquina que las contiene.

2. Facilidad para la paralelizaci´on de los c´alculos. El codigo fuente del programa no depende del n´umero de procesadoresdisponibles para su ejecuci´on.

3. Parametrizaci´on flexible. El usuario puede configurar par´ametros para prop´ositos de optimizaci´on. Por ejemplo ´el po-dra elegir el mejor servidor para ejecutar su programa gracias a la posibilidad de conocer un directorio de los recursosdisponibles en cada servidor.

4. Capacidad de crecimiento incremental. En cualquier momento es posible conectar y agregar nuevos servidores con ca-pacidades de c´alculo que permitan aumentar la eficiencia en la ejecuci´on de los programas existentes sin necesidad derealizar cambios en el c´odigo existente.

5. Portabilidad e interoperabilidad mediante el uso de las tecnolog´ıasJavaTM y CORBA/IIOP: Internet Inter-ORB Protocol.Esta elecci´on permitira a los elementos de software interoperar a´un cuando ellos hayan sido desarrollados por diferentesvendedores. Adem´as permitira adaptar f´acilmente el sistema a plataformas heterog´eneas (super computadores, estacionesde trabajo, computadores personales, etc.).

6. Preservaci´on de la inversi´on tecnologica mediante la creaci´on de componentes de software que encapsulen las aplica-ciones o m´odulos existentes, desarrollados bajo diferentes paradigmas, lo cual permitir´a la coexistencia entre los sistemasexistentes y los nuevos sistemas a desarrollar.

7. Integracion en el Web, permitiendo el uso de la interfaz del sistema desde cualquier parte.

SPIN puede ser considerado como un conjunto de servicios de alto nivel cuya implementaci´on podr´ıa basarse en una in-fraestructura de computaci´on tal comoGlobus.

Uno de los objetivos a largo plazo de este ambiente es atacar los problemas relacionados con la optimizaci´on de ciertosprocesos en ambientes de c´alculo heterog´eneos, asi como problemas relacionados con detecci´on automatica del paralelismoen ciertos c´alculos.

SPIN esta siendo desarrollado usando diferentes t´ecnicas orientadas a objetos, a diferencia de muchos otros proyectos quepersiguen los mismos objetivos. Entre las t´ecnicas utilizadas se puede mencionar:

– Especificaci´onnCORBA: Common Object Request Broker Architectureun estandar definido por elOMG: Object Man-agement Grouppara la interoperabilidad y portabilidad de aplicaciones distribuidas orientadas a objetos [22], [21],[20].

– ModeloPAC-Amodeusbasado en la noci´on demultiagentes, permite definir la arquitectura de un sistema interactivo [8][9].

– EnfoqueOOSE: Object-Oriented Software Engineeringpara modelar el componente del dominio del problema [17].– NotacionUML: Unified Modeling Languagepara la especificaci´on del modelo del componente del dominio del problema

[24], [25].– Lenguaje de programaci´onJavaTM , para implementar la interfaz usuario. En el desarrollo se aprovechar´an las facilidades

del lenguaje para definir, implementar y acceder los objetos CORBA [7], [19], [27], as´ı como tambien las facilidades parainteroperar con componentes escritos en otros lenguajes.

– InterfazAPIJDBCTM para la definici´on de clasesJavaTM que representan conexiones a la base de datos, instruccionesSQL, meta-datos, etc. Esta base de datos almacena la informaci´on de los usuarios (par´ametros por defecto, c´odigo fuente,etc.).

El resto de este art´ıculo esta estructurado de la manera que a continuaci´on se especifica. La secci´on 2 describe la arquitec-tura general de SPIN, la secci´on 3 describe la arquitectura de la aplicaci´on cliente del ambiente, la secci´on 4 contiene unadescripcion general del componente servidor y finalmente se presentan las conclusiones.

2 Arquitectura General

Para la definici´on de la arquitectura general del ambiente se ha seleccionadoCORBA: Common Object Request Broker, unconjunto de especificaciones publicadas por elOMG: Object Management Group. Estas especificaciones definen la maneraen la cual los objetos pertenecientes a una aplicaci´on distribuida son definidos, creados, despachados, invocados y la forma enla cual se establecen las comunicaciones entre ellos.

La figura 1 presenta la arquitectura general del ambiente, la cual est´a basada en el est´andar CORBA.

Figura1. Arquitectura general del ambiente

El ORB: Object Request Brokerestablece las relaciones de cliente-servidor entre los objetos. Usando el ORB, un cliente puedeinvocar, de manera transparente, un m´etodo que puede estar o no sobre la misma m´aquina. El ORB intercepta la llamada y esresponsable de encontrar el objeto referenciado, enviar los par´ametros del m´etodo, invocar el m´etodo y retornar los resultados.El cliente no tiene que involucrarse con los detalles acerca de la localizaci´on del objeto, el lenguaje de programaci´on en el cualesta implementado, el sistema operativo, ni ning´un otro aspecto que no sea parte de la interfaz del objeto. Gracias al protocoloIIOP, el ORB permite la interoperabilidad entre aplicaciones que se encuentran en un ambiente distribuido heterog´eneo.

El ORB usado para la implementaci´on del ambiente que se describe en este art´ıculo es provisto por Java IDL, en el JDK1.2. Ademas se utiliza el compiladoridltojava, para definir, implementar y acceder los objetos CORBA desde el lenguaje deprogramaci´on JavaTM . Java IDL satisface la especificaci´on CORBA/IIOP 2.0 y elIDL-to-Java Language Mapping[19],[22], [28].

Del lado del cliente se encuentra la interfaz usuario. Para este ambiente se ha desarrollado una interfaz gr´afica escrita en ellenguaje de programaci´on JavaTM . Esta interfaz puede ejecutarse en diversas plataformas (generalmente un computadorpersonal o una estaci´on de trabajo la cual posea una m´aquina virtual Java (JVM). El cliente no posee ning´un poder de c´alculo,el solo actua como un controlador de los servidores (generalmente super computadores de alto rendimiento).

La aplicacion cliente puede ser vista como un controlador centralizado de instrucciones de una m´aquina MIMD, cuyos proce-sadores son computadores d´ebilmente conectados, en el caso del ambiente se aprovechar´a la Internet, como red de inter-conexion. Esta visi´on sera usada en el futuro para proveer al ambiente de estrategias adaptadas para la repartici´on de la carga.

La aplicacion servidor est´a constituida por los recursos de c´alculo, los servicios de informaci´on. Los recursos de c´alculo sonlas bibliotecas espec´ıficas para c´alculo cient´ıfico junto a los objetos encapsuladores(wrappers)para aquellos componentesque as´ı lo requieren. Esta aplicaci´on conforma el n´ucleo funcional del ambiente.

Figura2. Funcionamiento general de la aplicaci´on cliente

El ambiente hace uso del protocoloHTTP: HyperText Transfer Protocolpara permitir al usuario recuperar la aplicaci´on clienteusando elweb browsercapacitado para ejecutar programasJavaTM y para recuperar, desde la base de datos, la informaci´onrelacionada con los servidores. La base de datos es actualizada a medida que la aplicaci´on cliente se ejecuta.

Un escenario t´ıpico del funcionamiento descrito anteriormente puede observarse en la figura 2:

1. En un Web browser capacitado para ejecutar programas Java, el usuario introduce la direcci´on URL que apunta hacia lapagina de conexi´on en el servidor Web.

2. El servidor Web recibe el requerimiento del usuario y retorna hacia el cliente una p´aginaHTML: HyperText MarkupLanguage. La pagina hace referencia alapplet Javael cual es cargado en la JVM del browser, iniciando la ejecuci´on dela aplicacion. Tambien se recupera la base de datos asociada.

3. La base de datos es actualizada con la informaci´on generada por el usuario: programas nuevos, modificaci´on de la listade servidores, etc. Los programas son escritos usando una interfaz gr´afica basada en la manipulaci´on de objetos. Losdatos (matrices, vectores, etc.) son representados como objetos los cuales son capaces de reaccionar ante est´ımulos ex-ternos, estos est´ımulos inician la ejecuci´on de las operaciones requeridas por los usuarios: suma de vectores, productos,factorizaciones, etc. En tiempo de ejecuci´on, las invocaciones de estas operaciones son traducidas por el INF en invo-caciones remotas a las funciones de bibliotecas que se encuentran en los servidores quien utiliza el protocolo IIOP paraenviarlas a los servidores v´ıa el ORB. Las funcionalidades de INF ser´an detalladas posteriormente 3. La planificaci´onde las invocaciones en cada servidor es realizada gracias a la informaci´on suministrada por los usuarios, quien indica elservidor que debe ejecutar una operaci´on particular. En el futuro se proporcionar´a un mecanismo para que la INF asigneautomaticamente el servidor que deber´a tratar cada operaci´on.

4. Los calculos realizados por un servidor pueden requerir datos almacenados en alg´un otro servidor, para recuperar estosdatos se realizan comunicaciones mediante el IIOP.

5. El servidor env´ıa los resultados a la aplicaci´on cliente.

3 Arquitectura del cliente

Como se mencion´o anteriormente el cliente est´a conformado por la interfaz usuario del ambiente, esta interfaz permite accdera las diversas funcionalidades para realizar operaciones de c´alculo para lo cual el usuario construye un programa dondeindica el flujo en el cual deben ser ejecutadas las operaciones por el requeridas. La arquitectura de este componente hasido dise˜nada usando el modeloPAC-Amodeus. Este modelo est´a basado en la noci´on de multiagentes e integra los modelosArch/Slinky y PAC. El modelo Arch/Slinky considera que un sistema interactivo est´a compuesto por: el N´ucleo Funcional(NF), la Interfaz con el N´ucleo Funcional (INF), el Controlador de Di´alogo (CD), el Componente de T´ecnicas de Presentaci´on(CTP) y el Componente de T´ecnicas de Interacci´on de Bajo Nivel (TIBN). El modelo PAC permite expresar la arquitecturade un sistema interactivo como una jerarqu´ıa de agentes especializados en la interacci´on con el usuario. La integraci´on deestos dos modelos es lograda mediante la reutilizaci´on de los componentes definidos por el modelo Arch/Slinky [9], y elrefinamiento del Controlador de Di´alogo en terminos de agentes PAC [8].

La figura 3 muestra las relaciones entre los componentes mecionados anteriormente.

A continuacion se describen los componentes que conforman la aplicaci´on cliente en t´erminos del modelo PAC-Amodeus:

– Interfaz con el Nucleo Funcional: este componente mantiene la asociaci´on entre los conceptos del dominio del problemay los conceptos propios del controlador de di´alogo, implementando las funciones de comunicaci´on y las eventuales trans-formaciones de los datos entre los distintos formalismos utilizados, como ejemplo se puede mencionar el caso particularde las matrices esparcidas; es necesario contar con una interfaz que permita consultar la informaci´on acerca de una ma-triz y transformarla en informaci´on que pueda presentada al usuario. La INF traduce los requerimientos capturados porel controlador de di´alogo en una forma que sea comprensible por el n´ucleo funcional. Las comunicaciones entre amboscomponentes se establece mediante el ORB.

– Controlador de Dialogo: tiene la responsabilidad del secuenciamiento de los requerimiento del usuario. El controlador dedialogo recibe eventos desde el n´ucleo funcional v´ıa la interfaz INF y desde el usuario v´ıa el componente de t´ecnicas depresentaci´on.El controlador de di´alogo est´a compuesto por una jerarqu´ıa de agentes PAC. Un agente PAC es una unidad de proce-samiento compuesta de tres perspectivas [8]:� Presentacion: define la imagen del agente, es el comportamiento perceptible por el usuario. Est´a relacionado con el

componente de t´ecnicas de presentaci´on. Un agente puede no tener perspectiva de presentaci´on.

Figura3. Arquitectura de la aplicaci´on cliente

� Abstraccion: es el nucleo de las funcionalidades del agente. Esta perspectiva mantiene el estado abstracto del agentey puede estar relacionada con algunos objetos conceptuales del componente N´ucleo Funcional.

� Control: permite establecer la comunicaci´on entre las perspectivas de Abstracci´on y Presentaci´on as´ı como con losotros agentes de la jerarqu´ıa.

Estas perspectivas son usadas para expresar funciones diferentes pero muy bien complementadas.La nocion de jerarqu´ıa introducida por el modelo PAC puede ser explotada ampliamente para definir niveles de abstrac-cion. El agente que se encuentra en la ra´ız de la jerarqu´ıa representa la interfaz con funcionalidades del sistema. Enlos niveles intermedios los agentes son usados para representar combinaciones de relaciones y de niveles abstracci´on.Una relacion tıpica es la relaci´on de composici´on, esto significa que un agente PAC puede estar compuesto por otrosagentes PAC, definiendo un nuevo nivel de abstracci´on. En el nivel m´as bajo de la jerarqu´ıa, se encuentran agentes PACelementales los cuales constituyen las unidades m´ınimas de interacci´on, como por ejemplo un bot´on, un men´u, etc.

– Tecnicas de Presentacion: este componente implementa la interacci´on fısica con el usuario v´ıa hardware y software. Est´acompuesto por los objetos abstractos que permiten representar la informaci´on que ser´a presentada a los usuarios, porejemplo: tablas, gr´aficos, etc. En nuestro caso se ubican en este nivel las t´ecnicas empleadas para la representaci´on graficade las matrices, en la figura 3 se muestra la representaci´on para matrices esparcidas basada en city-plot asi como unarepresentaci´on para el espectro de los valores propios de una matriz. Este componente contiene tambi´en los objetos queimplementan la t´ecnica seleccionada para representar los programas en construcci´on, en el caso de SPIN se ha elegido lametafora de un ´arbol general. La figura 4 ilustra la presentacion de los componentes de la interfaz usuario del ambientedefinidos para la construcci´on de un programa. Cada elemento es modelado como un agente PAC tal como se muestra enla figura 5.

Figura4. Interfaz usuario del ambiente: La ventana actual contiene tres marcos que representan los diferentes aspectos de un programa enconstruccion: su vision en forma de ´arbol, las propiedades de sus nodos y el c´odigo fuente

– Tecnicas de Interaccion de Bajo Nivel: este componente est´a representado por las facilidades provistas por la plataformasubyacente. Estas facilidades est´an constituidas por el sistema de ventanas, eltoolkit, etc. En el caso de nuestra aplicaci´onparticular se consideran para la implementaci´on las tecnicas provistas porJavaTMSwing [3], [16].

El modelo PAC-Amodeus est´a caracterizado por una estructura modular fuerte, por la comunicaci´on mediante eventos y laposibilidad de procesamiento concurrente o paralelo. Los eventos pueden ocurrir simult´aneamente y pueden involucrar agentesdiferentes, quienes pueden procesar estos eventos de manera paralela. Este modelo fomenta la pr´actica de di´alogos multi-hilosdonde cada agente est´a especializado en la manipulaci´on de un hilo.

El modelo PAC-Amodeus ha sido seleccionado por las siguientes razones:

– La separaci´on de aspectos efectiva, lo cual es una ventaja con respecto al modelo MVC, donde las funcionalidades de losagentes est´an dispersas entre las diferentes perspectivas [18], [8].

– El modelo explica exactamente como se realizan las comunicaciones entre los agentes.– La nocion de control facilita las comunicaciones.

La figura 5 presenta el diagrama PAC del controlador de di´alogo. Los agentes PAC han sido identificados a partir de lapresentaci´on de la interfaz mostrada en la figura 4. En el diagrama cada agente es representado como un conjunto de tresovalos, cada ´ovalo corresponde a una perspectiva.

Figura5. Diagrama PAC del Controlador de Di´alogo

Una descripci´on detallada de los agentes que conforman el controlador de di´alogo puede ser vista en [14].

4 Arquitectura del servidor

Esta aplicaci´on esta conformada por los servicios para el c´alculo cient´ıfico, asi como servicios comunes de operaci´on. En elcaso particular de este ambiente, se ha considerado el dominio de ´algebra lineal para la definici´on de los servicios de c´alculo.

4.1 Servicios de Calulo

Para el c´alculo cient´ıfico se utilizan los sistemas existentes junto a los objetos encapsulantes para aquellos elementos que asilo requieran.

Entre los sistemas existentes se encuentran las bibliotecas de c´alculo cient´ıfico usadas mas com´unmente por los investigadores,entre ellas se puede mencionar: BLAS, Sparskit, etc.

Los objetos encapsuladores(wrappers)corresponden a los adaptadores necesarios para usar los sistemas existentes. Estosobjetos son necesarios para lograr la interoperabilidad con las funciones de bibliotecas que no han sido desarrolladas bajo el

paradigma de la orientaci´on a objetos, cumpliendo as´ı uno de los objetivos planteados en el dise˜no del ambiente: preservar lainversion tecnologica realizada.

Los wrappersson desarrollados usando la Interfaz Nativa de Java (JNI). La JNI permite que un c´odigo que se ejecuta sobreuna maquina virtual Java pueda operar con aplicaciones escritas en otros lenguajes, tales como C, C++ o FORTRAN.

Tambien se han identificado nuevos componentes para la realizaci´on de nuevos m´etodos num´ericos los cuales han sido im-plementados usando t´ecnicas orientadas a objetos. Para el an´alisis y dise˜no de estos nuevos componentes se ha utilizado unmetodo orientado a objetos basado en el enfoque de casos de uso [17]. A continuaci´on se describe brevemente los principaleselementos subsitemas de c´alculo definidos a partir de este an´alisis de requerimientos.

1. Subsistema Matrices: Este componente engloba un conjunto de objetos que permite representar los diversos tipos dematrices que pueden manipuladas por los m´etodos de c´alculo cient´ıfco. Cada uno de estos objetos contiene los atributosque definen las caracter´ısticas del tipo particular de matriz asi como las operaciones b´asicas que permiten su manipulaci´on.Los diferentes tipos de matriz se definen en t´erminos de:

– proporcion de elementos nulos.– numero de dimensiones.– distribucion de los elementos no nulos.

Entre las operaciones b´asicas se puede mencionar: suma, c´alculo de normas, producto, etc. La implementaci´on de estasoperaciones var´ıa en funcion del formato en el cual son almacenados almacenados los valores de la matriz, y en t´erminosde la arquitectura sobre la cual se ejecutar´an los calculos.

2. Subsistema metodos numericos: contiene la definici´on e implementaci´on de los distintos m´etodos para resolver sistemasde ecuaciones lineales y para calcular valores y vectores propios. Estos m´etodos pueden ser directos o iterativos. Suimplementaci´on varıa de acuerdo a la utilizaci´on o no de diversas t´ecnicas de optimizaci´on tal como la t´ecnica de pre-condicionamiento y al igual que para la implementaci´on de las operaciones del subsitema matrices se puede utilizar unmodelo secuencial o un modelo paralelo.

Los nuevos objetos descritos anteriormente est´an implementados en C++. Esta elecci´on se realiz´o debido a queJavaTM

aun no provee de mecanismos eficientes para el c´alculo cient´ıfico, en particular es necesario que se realicen mejoras en lossiguientes aspectos [1]:

– Aritmetica de punto flotante.– Aritmetica compleja.– Arreglos multidimensionales.– Sobrecarga de operadores.

Sin embargo actualmente se est´an realizando mejoras en este sentido lo cual permitir´ıa aprovechar todas las ventajas dellenguajeJavaTM tambien en elarea de c´alculo cient´ıfico.

Las diferentes etapas del an´alisis de este componente, asi como el diagrama conceptual de clases puede ser visto en [14].

4.2 Servicios Comunes

En SPIN se ha definido un conjunto de servicios comunes que son requeridos por todas las aplicaciones para su buen fun-cionamiento, estos servicios incluyen, facilidades para al acceso a datos persistentes, servicios de directorio, etc.

A continuacion se presenta una descripci´on general de estos servicios.

– Directorio: este servicio permite a las aplicaciones obtener informaci´on en tiempo real, sobre la estructura y el estado delsistema. Esta informaci´on incluye: actividad del sistema, capacidad de memoria de los procesadores, velocidad del CPU,bibliotecas disponibles en los procesadores, etc. La informaci´on es usada para tomar decisiones de configuraci´on de laaplicacion.

– Acceso a los Datos: este servicio permite acceder a los datos persistentes tales como el c´odigo fuente de los programas deusuario, etc.

5 Conclusiones y Perspectivas

En este art´ıculo se ha presentado una visi´on global de un caso de estudio en la aplicaci´on de metodos y tecnicas orientadasa objeto, as´ı como de tecnicas de sistemas de objetos distribuidos. Se ha descrito la arquitectura general de un ambienteintegrado e interactivo para los investigadores en el ´area de c´alculo cient´ıfico a gran escala. El ambiente ha sido dise˜nadocomo una aplicaci´on basada en objetos distribuidos siguiendo el est´andar CORBA.

El ambiente ha sido concebido para proveer las siguientes ventajas:

1. Independencia de plataformas.2. Facilidad para la paralelizaci´on de los c´alculos.3. Capacidad de crecimiento incremental.4. Portabilidad e interoperabilidad.5. Preservaci´on de la inversi´on tecnologica.6. Integracion en el Web.

Otra ventaja es la facilidad de uso mediante una interfaz gr´afica, la cual ha sido modelada siguiendo un enfoque basado en lanocion de multiagentes. La separaci´on entre los aspectos de interacci´on con el usuario, los servicios para el soporte al c´alculonumerico y los servicios para el acceso remoto a los recursos es un elemento importante que permiti´o la implementaci´onindependiente de cada faceta a partir de interfaces bien definidas

Los metodos usados constituyen un medio eficiente para capturar los requerimientos de los usuarios y permiten realizar unaseparaci´on efectiva de los aspectos funcionales y de interfaz usuario. Las notaciones usadas para expresar los diferentesmodelos constituyen un medio eficiente para lograr la comunicaci´on con los usuarios.

En el futuro se espera evaluar el ambiente con aplicaciones reales en particular se considerar´a una herramienta para tomograf´ıasismica. Esta aplicaci´on requiere de la resoluci´on de sistemas de ecuaciones lineales de gran tama˜no.

Tambien se espera proveer mecanismos para la detecci´on automatica del paralelismo y para la optimizaci´on de la ejecuci´onen ambientes de c´alculo heterog´eneos.

Referencias

1. Making Java Work for High-End Computing, 1998.2. JAMA : A Java Matrix Package, 1999. http://math.nist.gov/javanumerics/jama/.3. Marc Andrews. What Is Swing - 1. Getting Started with Swing. http://java.sun.com, march 1999.4. S. Atlas, S. Banerjee, J. Cummings, P. Hinker, M. Srikant, V. Reynders, M. Tholburn, W. Humphrey,

S. Karmesin, and K. Keahey. POOMA : A Framework for Scientific simulation on parallel Architectures.http://www.acl.lanl.gov/PoomaFramework/papers/pooma.ps.

5. S. Balay, W. Gropp, L. Curfman, and B. Smith.PETSc 2.0 Users Manual. Argonne National Laboratory, 1996. ANL-95/11 - Revision2.0.24.

6. R Barret et al.Templates for the Solution of Linear Systems : Building Blocks for Iterative Methods. SIAM, Philadelphia, 2nd edition,1994.

7. Cliff Berg. The State of Java Application Middleware.JavaWorld, March 1999.8. J. Coutaz.Interface Homme-Ordinateur. Dunod, France, 1990.9. J Coutaz.Formal Methods in Human-Computer Interaction, chapter 3. Software Architecture Modelling: Bridging Two Worlds Using

Ergonimics and Software Properties, pages 49–73. Formal Approaches to Computing Information Technology. Springer, 1998.10. J. Dongarra et al. LAPACK Working Note, 1995. http://www.netlib.org/utk/papers/pblas/pblas.html.11. J. Dongarra, R Pozo, and D Walker. LAPACK : A Design of Object-Oriented Extensions for High Performance Linear Algebra.

Proceedings of the Supercomputer 93 Meeting, pages 162–171, November 1993.12. I. Foster and C. Kesselman. Globus: A Metacomputing Infraestructure Toolkit. InIntl J. Supercomputer Applications, volume 11, pages

115–128. 1997.13. I. Foster and C. Kesselman. The Globus Project: A Status Report. InHeterogeneus Computing Workshop, pages 4–18, 1998.

14. M. Gonzalez and S. Petiton. Un Modelo de Interfaz Usuario para un Ambiente de Resoluci´on de Sistemas de Ecuaciones Lineales. InMemorias de la XXV Conferencia Latinoamericana de Inform´atica. CLEI, 1999.

15. Inc. The Math Works. MATLAB. Reference Guide, 1992.16. Mageland Institute. Fundamantals of JFC/Swing, Part 1. Short Course. Online Traning. Java Developers Connection.

http://java.sun.com, april 1999.17. I. Jacobson, M. Christenson, P. Jonsson, and G.Overgaard. Object-Oriented Software Engineering. A Use Case Driven Approach.

Addisson-Wesley Publishing Company, New York, 1992.18. G. Krasner and S. Pope. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80.JOOP, pages

26–49, 1988.19. Sun Microsystems. Java IDL. Technical report, 1998.20. Object Mangement Group Inc. A Discusion of the Object Management Architecture. http://www.omg.org/library/oma/oma-all.ps.21. Object Mangement Group Inc. OMA An Executive Overview. http://www.omg.org/about/omaov.htm.22. Object Mangement Group Inc. The Common Object Request Broker : Architecture and Specification.

ftp://ftp.omg.org/pub/docs/formal/98-02-01.ps.gz.23. Y. Saad. SPARSKIT: A Basic Tool Kit for Sparse Matrix Computations. Technical Report 90-20, NASA Ames Research Center, 1991.24. Rational Software Corporation. UML Notation Guide. http://www.rational.com/-uml/html/notation.25. Rational Software Corporation. UML Summary. http://www.rational.com/uml/html/summary.26. G. W. Stewart. JAMPACK: A Java Package for Matrix Computations. Department of Computer Science. Institute

for Advanced Computer Studies. University of Meryland and Mathematical and Computations Sciences Division. NIST.ftp://thales.cs.umd.edu/pub/Jampack/Jampack/AboutJampack.html, 1999.

27. Sun Microsystems. TheJavaTM Language: An Overview. Technical report, 1995.28. Sun Microsystems et all. IDL/Java Language Mapping. Technical Report orbos/97-02-01, Object Management Group, 1997.