Instituto Tecnológico de Acapulco

4.1. ESPECIFICACIONES DE ALTO NIVEL

Esta parte trata lo relacionado a las especificaciones de aplicaciones distribuidas, que comúnmente tienen un gran número de requerimientos de desempeño que los hace difíciles de especificar. En primer lugar, típicamente son concurrentes, además, requieren ser altamente confiables y disponibles, y también deben ofrecer rápidos tiempos de respuesta.
Resulta relativamente fácil describir un sistema distribuido dando una explicación detallada de su implementación, por ejemplo; dónde se localiza la información, cuántas réplicas de la información existen, cómo se procesan las peticiones y cómo se comunican todas las piezas del sistema. Así como las especificaciones del usuario para programas secuenciales, las especificaciones de sistemas distribuidos deberían expresarse en términos orientados al usuario y deberían ser libres de detalles de implementación.
Un sistema distribuido es un objeto abstracto que puede usarse invocando a varias operaciones, así que el sistema es una instancia de un tipo de datos abstracto. Las especificaciones de un sistema describen todas las constantes relevantes en su comportamiento observable; incluyendo el comportamiento de las operaciones invocadas por los usuarios y si el sistema esta activo, las operaciones que el sistema realizará internamente.
El usuario de un sistema podría ser un programa o proceso, o si el sistema es interactivo, una persona. Un sistema puede tener usuarios que trabajen concurrentemente y todos estos usuarios pueden invocar sus operaciones en paralelo.
En las especificaciones, cada operación es vista como una acción atómica. Estas operaciones atómicas poseen dos propiedades importantes: serializabilidad y totalidad. La serializabilidad se refiere a que la ejecución concurrente de un grupo de acciones es equivalente a la ejecución secuencial de las mismas operaciones. La totalidad quiere decir que cada operación, o se ejecuta total y exitosamente, o falla y no tiene efecto sobre el estado del sistema.

La técnica básica que es usada en la escritura de especificaciones es introducir especificaciones no deterministas en el modelo que describa la propagación de la información sobre todas las réplicas y los efectos de no serializabilidad de las operaciones concurrentes. También es de ayuda estructurar las especificaciones, de manera que se puedan distinguir los efectos esperados y no deseados, de los inesperados. Esta distinción es importante tanto para usuarios como para los implementadores del sistema, y hace que las especificaciones sean fáciles de entender.

Se mostrará con ejemplos la forma acercarse a especificar sistemas distribuidos, describiendo la implementación de un sistema, y posteriormente especificar el sistema en términos orientados al usuario.

Un diccionario distribuido.

El diccionario es modelado como un conjunto, con una operación insertar para agregar un elemento al conjunto, borrar para remover un elemento y listar para observar los miembros del conjunto. El diccionario podría implementarse en un sistema distribuido, consistente de un conjunto de nodos conectados por una red. El objetivo es hacer al sistema altamente disponible, en el sentido de que cualquiera de los nodos con posibilidades de operar, deberían ejecutar cualquiera de las tres operaciones en cualquier momento, sin importar el estado de la red o de los otros nodos.

La implementación funciona procesando cada operación en un sólo nodo, cada uno de los cuales cuenta con una copia del diccionario. Si se realiza una operación de inserción o eliminación en un nodo, sólo se actualiza la copia de ése nodo, y posteriormente, por medio del envío de mensajes, se propagan las modificaciones a los demás nodos del sistema. Debido a que un nodo puede no saber de las operaciones ejecutadas en otros nodos, se requiere que los usuarios se aseguren que los elementos dados sean insertados al menos una vez, y que un elemento sea borrado sólo si este ha sido insertado anteriormente, y el nodo que realizará la eliminación sepa de la inserción.
En la especificación, el diccionario es tratado como un recurso centralizado, su implementación distribuida es irrelevante. El estado del diccionario es modelado como un par de conjuntos, Miembros y Exmiembros. Miembros contiene todos los elementos que han sido insertados, mientras que Exmiembros contiene todos los elementos que han sido eliminados.

A continuación se muestra la forma usada en la especificación. La especificación de cada operación consiste en un encabezado seguido por un número de cláusulas. El encabezado describe los tipos de los argumentos y los resultados. La cláusula opcional requerimientos describe las asunciones que hace la operación acerca de los argumentos y el estado del sistema cuando es llamado. Finalmente, la cláusula efectos describe el comportamiento de la operación cuando se satisfacen las asunciones en la cláusula requerimientos; si no se satisface la cláusula requerimientos cuando es llamada la operación , entonces la especificación no coloca alguna constante en el comportamiento de la operación.

insertar = procedimiento(x: elemento)
requiere x ? Miembros
efectos Agrega x a Miembros
borrar = procedimiento(x: elemento)
requiere x ? Miembros
efectos Agrega x a Exmiembros
listar = procedimiento() regresa (secuencia[elemento])
efectos Regresa un subconjunto de Miembros

Al igual que en cualquier tipo de dato abstracto, las operaciones del diccionario pueden clasificarse como constructores, que modifican el estado, y observadores, que leen el estado.

La especificación dada como ejemplo no concuerda en un aspecto con la especificación mencionada anteriormente: la cláusula requerimientos de la acción borrar no enfatiza la restricción de que el nodo en el que se lleva a cabo la eliminación debe conocer la inserción del elemento que será eliminado.

La especificación dada anteriormente describe el comportamiento del diccionario en un alto nivel, en términos orientados al usuario, pero no captura algunos aspectos importantes de su comportamiento. En particular, no indica que regresará una operación de listado. Se sugiere el siguiente enfoque: dividir la cláusula efectos en dos partes, los efectos normales y los efectos anormales. Los efectos normales describen lo que ordinariamente espera ver un usuario, por ejemplo, cuando todos los nodos están activos y la información es propagada en todos los nodos. En efecto, describe un sistema ideal en el cual, todas las modificaciones son observables inmediatamente. Los efectos anormales describen eventos no deseados, por ejemplo, lo que ocurre cuando hay un problema como una partición de red. Describe situaciones donde la implementación sólo se acerca a un sistema ideal. A continuación se revisa la especificación para la operación listar del diccionario.

listar = procedimiento() regresa (secuencia[elemento])
efectos normales Regresa Miembros - Exmiembros
efectos anormales Regresa un subconjunto de Miembros

Nótese que el comportamiento normal de la operación listar es regresar exactamente los elementos que han sido insertados y que no han sido eliminados; aunque es posible que regrese algunos elementos que han sido eliminados, o no regresar algunos elementos que hayan sido insertados, este comportamiento es el anormal.

4.2. ESTÁNDARES

Se puede observar que los objetivos del diseño de sistemas son muy amplios y afectan aspectos tanto de la aplicación como de la organización en la que será utilizado el sistema. Por consecuencia, no debe sorprender el hecho de que los grupos de sistemas de información mejor manejados, también mantengan estándares para el desarrollo de sistemas. Las especificaciones de diseño se establecen dentro del marco fijado por los estándares.

Áreas en el diseño de estándares:

•Estándares para datos:

Lineamientos para asignar un nombre a los datos y especificar su longitud y tipo. Estos lineamientos son utilizados por todas las aplicaciones desarrolladas por el grupo de sistemas de información. Con frecuencia están contenidas en el diccionario de datos.

•Estándares de especificación:

Abreviaturas y Designaciones formales para describir actividades y entidades dentro de la organización (Por ejemplo, clasificación de clientes y tipos de transacciones) .

•Estándares estructurales

•Lineamientos sobre como estructurar el software y el sistema.

Políticas para dividir el software en módulos, para la codificación estructurada y la relación existente entre los componentes del sistema. Puede incluir estándares sobre la longitud del programa y lineamientos para volver a utilizar los módulos de software.

•Estándares de documentación:

Descripciones de las características del diseño de sistemas, de la relación entre componentes y de las características de operación que pueden ser revisadas para conocer los detalles de aplicación.

Proyecto ANSA

Los estándares surgieron primero como un campo de la ingeniería y se formaron grupos para concordar en las unidades de medición y en prácticas de la ingeniería. La Interconexión de Sistemas Abiertos (OSI, por sus siglas en inglés) surgió en forma similar, y esta arquitectura ha ganado importancia al ofrecer una plataforma alternativa en comunicaciones para las arquitecturas dominantes.

Para los sistemas distribuidos son necesarios los estándares por dos razones:

1.Diversidad. Por naturaleza, los seres humanos cotidianamente son 'distribuidos': trabajan en diferentes lugares y la recolección y almacenamiento de la información se realiza en diferentes locaciones. Para lograr la mejor interacción hombre - computadora, respuestas rápidas e independencia, es necesario colocar a las computadoras cerca de las personas que las usan, lo que lleva al concepto de computación personal. Sin embargo, las personas requieren de compartir información y procesos. Los sistemas distribuidos se tienen que adaptar a diferentes requerimientos operacionales. Por ejemplo, la automatización de una fábrica requiere respuestas en tiempo real y un alto grado de confiabilidad; la aplicaciones en una oficina requieren alta seguridad en lugar de respuestas en tiempo real.

2.Fragmentación. Hasta ahora, no existe una arquitectura abierta que facilite la construcción de sistemas distribuidos en una base de diversos vendedores, la cual pueda expandirse a diversos dominios de aplicación.
El proyecto ANSA (Andvanced Networked Systems Architecture, Arquitectura de Sistemas Avanzados en Red), surgió como una propuesta a la necesidad de una arquitectura que fuera capaz de abarcar sistemas que soportaran aplicaciones distribuidas y para adoptar un estándar que abarque a toda la industria de la informática.

ANSA es el resultado de la unión y del trabajo de ocho diferentes compañías de la industria de la información o informática. Las empresas que se unieron a este proyecto son: British Telecom, Digital Equipment Corporation, The General Electric Company/Marconi, Hewlett Packard, International Computers Limited, Information Technology Limited, Oliveti Research Ltd, Plessy Office & Networked Systems y Racal.

Algunas de las actividades en las que se ha involucrado el proyecto ANSA ha sido en la estandarización, teniendo como ejemplo que aproximadamente la mitad de los documentos del actual estándar OSI Open Distributed Processing (OSI Procesamiento Distribuido Abierto), fueron originados a partir de ANSA. Un logro mayor del proyecto, es ANSA Testbench, que es un conjunto de software el cual provee una referencia de implementación para demostrar el uso de los principios de ANSA; básicamente, el conjunto de software ofrece una mayor facilidad en la administración de llamadas a procedimientos remotos (RPC) y además, una serie de herramientas que facilitan la escritura de aplicaciones distribuidas.

Los temas principales del proyecto ANSA son la integración y los estándares, y uno de los enfoques principales del proyecto es establecer la integración de aplicaciones provenientes de diferentes vendedores, creando una arquitectura común para sistemas de computación distribuida. Los esfuerzos del proyecto se centran en la definición de modelos, interfaces y estándares.

La misión del proyecto ANSA se concentra en tres apartados:

1.Proveer un núcleo de conceptos sobre los cuales se puedan cristalizar la ideas de la arquitectura de sistemas distribuidos.

2.Proveer un modelo de referencia para el procesamiento distribuido en orden de definir estándares, y aplicar esos estándares a los sistemas distribuidos.

3.Demostrar la posibilidad de la integración agregando esos estándares, basado en la aplicación de nuevos prototipos de protocolos y servicios.
Estos tres aspectos se concretizan en dos tipos de objetivos del proyecto:

Objetivos de coordinación.

•Estándares. Construir y mantener en los proyectos una conciencia de contribuciones técnicas dentro del proceso de estándares internacionales.

•Transferencia de tecnología. Proveer conocimiento técnico para asistir en la formulación de una explotación industrial de procesamiento abierto distribuido.

•Diseminación. Publicar anualmente los resultados del proyecto, en forma de actualizaciones y versiones extendidas del Manual de Referencia ANSA y liberaciones posteriores del ANSA Testbench.

Objetivos técnicos.

•Fundaciones. Desarrollar conceptos de arquitectura, técnicas de modelado y taxonomías por las cuales se pueda describir consistentemente a los sistemas de procesamiento distribuido.

•Ingeniería. Desarrollar y especificar métodos de ingeniería que serán requeridas por diseñadores de aplicaciones distribuidas.

•Productividad. Mejorar la productividad en la construcción e interconexión de aplicaciones integradas de procesamiento por medio de la provisión de un conjunto de bloques de construcción.

4.3. HERRAMIENTAS DE DISEÑO

Los principios comunes del diseño, proveen un modelo consistente de procesamiento de información a través de un sistema, el cual facilita la tarea de integrar diversos paquetes de aplicaciones en un sistema coherente.

Para los operadores de sistemas, el diseño marca un acercamiento a la administración diaria de los sistemas, además del crecimiento integral del sistema para ajustar los nuevos requerimientos y los cambios en la industria de la tecnología de información.

Para los desarrolladores de sistemas, los principios de diseño deben aumentar la productividad, mejorar la reusabilidad del software y facilitar la generación automática de software, a partir de sentencias declarativas de requerimientos. El uso de los principios de diseño reduce también, el tramo que separan la interconexión de sistemas separados, simplificando la complejidad de interconexión y extendiendo el rango de componentes que pueden ser interconectados.

Las herramientas de diseño apoyan el proceso de formular las características que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades de análisis:

•Herramientas de especificación
Apoyan el proceso de formular las características que deben tener una aplicación, tales como entradas, salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos.

•Herramienta para presentación
Se utiliza para describir la posición de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida.

Los analistas han utilizado las herramientas para el diseño de sistemas desde el inicio de la era de las computadoras. Sin embargo, la reciente infusión de ayuda computarizada así como la facilidad de generar gráficas de gran calidad están dando a estas herramientas un nuevo significado en el diseño de sistemas.

•Herramientas para el desarrollo:Estas herramientas ayudan al analista a trasladar los diseños en aplicaciones funcionales:

•Herramientas para la ingeniería de software

Apoyan el proceso de formular diseños de software, incluyendo procedimientos y controles, así como la documentación correspondiente.

•Generadores de código

Producen el código fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas.

•Herramientas para pruebas

Apoyan la fase de evaluación de un sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operación del sistema así como el grado de perfección alcanzando en comparación con las expectativas.

El soporte automatizado para el proceso del diseño y creación de software ha existido por muchos años en la forma de herramientas CASE (Diseño Asistido por Computadora, por sus siglas en inglés) y se han utilizado ampliamente metodologías de la Ingeniería del Software o Ingeniería de la Información para dar soporte en todo el ciclo de vida del desarrollo de aplicaciones en ambientes centralizados. El uso de dichos métodos para el desarrollo de aplicaciones distribuidas se ve limitada, debido a que no ponen la atención requerida en la particionabilidad de las aplicaciones y la distribución de la información. Aún más, la filosofía top - down de las metodologías tradicionales de análisis y diseño entran en conflicto con los requerimientos de los ambientes distribuidos que existen hoy en día, pues los sistemas distribuidos y las aplicaciones cliente/servidor se construyen típicamente a partir de componentes de software desarrollados por separado, utilizando una integración bottom - up. Actualmente, un número de herramientas CASE líderes en el mercado se han extendido para dar soporte al desarrollo de aplicaciones distribuidas. Algunos ejemplos de ellas son: Navigator (Ernst & Young), TCSM (The Client Server Methodology, James Martin & Co.), System Engineer (LBMS) y Oracle CASE, entre otras.

En algunos casos, tenemos disponibles algunas interfaces de lenguajes de cuarta generación (4GL) para facilitar la integración entre las herramientas para el desarrollo de aplicaciones y las herramientas CASE (por ejemplo; LBMS System Engineer se enlaza con PowerBuilder). La combinación de las tecnologías 4GL y CASE provee una mejor cobertura en el desarrollo cliente/servidor, pues las herramientas CASE se enfocan al diseño del servidor y las 4GL se enfocan en el desarrollo del lado del cliente.

La efectividad de estas soluciones híbridas depende en el nivel de integración logrado, en particular en el area del diccionario de datos.

Las herramientas de desarrollo existentes pueden ser mejor descritas como ambientes 4GL y se centran principalmente en la aplicación del lado del cliente. Algunas de las más populares son SQL Windows (Gupta Corp.), PowerBuilder (Powersoft Corp.), Access y Visual Basic (Microsoft Corp.). En general, estas herramientas no proveen soporte para el ciclo de vida del desarrollo de una aplicación y existen dudas sobre su escalabilidad. La efectividad de estas herramientas ha sido probada en proyectos de tamaño pequeño, sin embargo no ha sido probada su efectividad en aplicaciones grandes de misión crítica.

A continuación se describen en resumen, tres de los conjuntos de componentes disponibles en el mercado para el desarrollo de aplicaciones distribuidas: CORBA, DCE y DCOM.

CORBA (Common Object Request Broker Application).

CORBA ha existido desde 1990, y a partir de 1992 existen implementaciones comerciales. Fue creado por el Grupo de Administración Abierta (OMG, por sus siglas en inglés) [CORBA298]. En un nivel básico, CORBA es un estándar de objetos distribuidos. Permite que una aplicación solicite una operación a ser ejecutada por un objeto distribuido, el que regresará resultados a la aplicación solicitante. Los datos pueden pasar del cliente al servidor y están asociados a una operación en particular en un objeto en particular, luego se regresan datos al cliente en la forma de una respuesta.

Un objeto distribuido es un objeto que puede ser accesado remotamente. Esto significa que es un objeto común que puede ser usado desde cualquier parte en una red. Se considera que un objeto encapsula datos y un comportamiento. Los objetos ditribuidos son útiles en los siguientes casos:
·Compartir información entre aplicaciones o usuarios.
·Sincronizar actividad entre varias máquinas.
·Incrementar el rendimiento asociado con una tarea en particular.
·Conectar aplicaciones ejecutando en computadoras personales (PC) con información administrada por procesos UNIX, o bases de datos sobre mainframes.
·Permitir que las personas en diferentes ciudades contribuyan a un proceso particular de alguna empresa.
·Distribuir la potencia de cómputo entre diferentes redes.

CORBA provee de comunicaciones en un modelo solicitud - respuesta, a un bajo nivel, además de otros servicios colocados por encima de la comunicación. Esto convierte a CORBA en una infraestructura y no una herramienta para definir aplicaciones de alto nivel.

DCE (Distributed Computing Environment).

DCE fue creada por la Fundación de Software Abierto (OSF, por sus siglas en inglés), que ahora se denomina Open Group [DCE98]. Consiste en múltiples componentes que han sido integrados para trabajar en conjunto. A continuación se listan los componentes que conforman a DCE:

•Llamadas a procedimientos remotos (RPC).
•Servicios de directorio globales e individuales (CDS y GDS).
•Servicios de seguridad.
•Hilos de ejecución DCE.
•Servicio de tiempo distribuido (DTS).
•Sistema de archivos distribuidos (DFS).

Al igual que CORBA, DCE no es una aplicación, pero se utiliza en la creación de aplicaciones.

Son varias las ventajas de los componentes DCE:

•DCE provee de servicios que se encuentran disponibles en varios ambientes de trabajo en red. Por ejemplo, el servicio RPC facilita la comunicación entre módulos de software ejecutando en diferentes sistemas, haciéndolo de una forma más simple que otros métodos más antiguos como los sockets.

•Provee nuevas capacidades que van más allá de lo que existe en el mercado con anterioridad. Los servicios de seguridad proveen una forma confiable de determinar si un usuario tiene los derechos para utilizar un determinado recurso o ejecutar alguna acción.
·Integra componentes en una forma que los hace de más valor si se utilizan en conjunto, que si son utilizados por separado. Por ejemplo, RPC utiliza hilos de ejecución lo que posibilita al desarrollador de escribir servidores de múltiples hilos sin tener que crear o destruir explícitamente los hilos.

•Finalmente, DCE es portable y soporta interoperabilidad, ofreciendo posibilidades para que el desarrollador oculte las diferencias entre los diversos tipos de hardware, elementos de software y de red. La portabilidad es una medida de la facilidad con que un componente de software que se ejecuta en un hardware, sea llevado para que ejecute en una máquina de tipo diferente. La interoperabilidad es una medida de la posibilidad de las computadoras de diferentes tipos para participar en el mismo sistema.

Se podría suponer que existiese alguna relación de DCE con CORBA, pero no es así y cada una tiene sus ventajas y desventajas sobre la otra. DCE provee una programación de más bajo nivel de lo que hace CORBA y no está orientado a objetos y DCE tiene mejor interoperabilidad que los actuales productos de CORBA.

DCOM (Distributed Component Object Model).

DCOM es la tecnología que permite que componentes de software se comuniquen entre ellos a través de redes de computadoras, incluyendo Internet e intranets [MSTECH1296]. Los componentes son series de módulos de software preconstruidos, que tienen como propiedades su fácil desarrollo y entendimiento.
DCOM se caracteriza por lo siguiente:

•Rapidez en el desarrollo. Permite a los desarrolladores construir soluciones más rápido, ensamblando software a partir de partes preconstruidas.

•Reducción de los costos de integración. Se requiere menos tiempo para integrar componentes en soluciones completas, ya que existen conjuntos de interfaces comunes, distribuidas por diferentes proveedores.

•Reducción de los costos de mantenimiento. Al aislar la función del software en pequeños componentes provee un mecanismo eficiente de bajo costo para actualizar un componente sin tener que rediseñar toda la aplicación.

•Una arquitectura de componentes distribuidos aplica estos beneficios a las aplicaciones multiusuarios y DCOM cuenta con tres puntos clave que lo hacen una solución completa para lograr eso.

•DCOM se basa en la tecnología de componentes más usada actualmente. DCOM es una extensión de COM (Component Object Model), que es la tecnología de objetos inmersa en Microsoft ActiveX. Algunos de los vendedores más grandes del mundo ofrecen herramientas para el desarrollo de software que nos posibilitan producir componentes ActiveX, entre ellos podemos mencionar a Microsoft, Borland, PowerSoft/Sybase, Symantec, ORACLE, IBM y Micro Focus.

•DCOM es la mejor tecnología de redes para llevar la tecnología de componentes al Internet. Debido a que es una tecnología ActiveX, DCOM trabaja naturalmente con las tecnologías de Internet como TCP/IP, el lenguaje Java y el protocolo HTTP, posibilitando que las aplicaciones se extiendan al Web.

•DCOM es una tecnología abierta que se ejecuta en diversas plataformas. Esta diseñado para ejecutar en Windows 95, Windows NT, Macintosh, UNIX y otros sistemas operativos propietarios.