UNIDAD 4 METODOLOGÍA PARA EL DESARROLLO DE PROYECTOS EN SISTEMAS DISTRIBUIDOS.

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 [Mullender89] . 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.


4.2 Estándares.


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.


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 separa la interconexión de sistemas separados, simplificando la complejidad de interconexión y extendiendo el rango de componentes que pueden ser interconectados.


4.4 Documentación de sistemas distribuidos.


El ciclo de vida del desarrollo del software contempla a la documentación como una etapa de gran importancia para el producto final. Resulta crucial guardar las especificaciones establecidas que fundamentan el funcionamiento del software, así como de los componentes a partir de los que se forma la aplicación final. Una metodología tiene la finalidad de dirigir al desarrollador a una ruta racional, apuntando a las necesidades a satisfacer, en que orden y cuanto tiempo debe tomar cada actividad.


Durante el análisis de requerimientos se debe desarrollar una especificación de tales requerimientos, plasmada en un documento que sirve para especificar los requerimientos de los usuarios y es además, un punto de partida para el diseño. Distingue siete roles de usuarios para la documentación del diseño:


1. El administrador del proyecto requiere información para planear, controlar y administrar el proyecto. Debe estar en posibilidades de identificar cada componente del sistema y entender su propósito y funcionamiento.

2. El administrador de configuración necesita información para poder ensamblar varios componentes en un solo sistema y poder controlar los cambios.
3. El diseñador requiere de información acerca del uso y funcionamiento de cada componente, y su interfaz con otros componentes.
4. El programador debe conocer los algoritmos que se utilizarán, las estructuras de datos y la comunicación entre componentes.
5. Se requiere que el probador de unidades conozca información detallada de los componentes, como algoritmos y datos requeridos.
6. Al probador de integración le corresponde conocer las relaciones entre componentes y la función y uso de los componentes envueltos.
7. El programador de mantenimiento debe tener una visión de cómo se satisfacen los requerimientos usando todos los componentes.

Cada modulo (entidades o personas enroladas en el desarrollo) cuenta con una serie de atributos, entre los que se mencionan los siguientes:


· Identificación. Un nombre para hacer referencia a un componente. Debe ser único.

· Tipo. El tipo del componente, puede ser un procedimiento, un archivo.
· Función. Para lo que el componente fue diseñado.
· Subordinados. De cuales entidades se compone un módulo.
· Dependencias. Es una descripción de las relaciones con otros componentes.
· Interfaz. Es una representación de la interacción entre los componentes.
· Recursos. Son entidades externas al diseño, tales como memoria, impresoras, procesadores.
· Procesamiento. Se refiere a los algoritmos utilizados y el tratamiento a las excepciones.
· Datos. Una descripción de la representación, uso, formato y réplicas de los datos.

Como una buena práctica para un sistema distribuido, se recomienda establecer desde los documentos de especificación, todo lo referente al ambiente técnico en el que se planea funcione el sistema. Se deben establecer al menos los siguientes aspectos técnicos:


· Las plataformas de hardware a utilizarse.

· El o los sistemas operativos utilizados en cada nodo.
· El administrador de base de datos a usar.
· El software de red elegido.
· Los lenguajes seleccionados para el desarrollo.
· El medio o tecnología de red para conectar a los nodos.

1 comentario:

  1. Hola, me gustaría saber de donde tomaron la referencia de esta metodología por favor

    ResponderEliminar