Arquitecturas de Software

Ingeniera de Software
Arquitecturas de software
Instituto tecnolgico de Nogales

Materia: Ingeniera de software Nombre del profesor: Ing.- Erick Martnez Romero Tema: Arquitecturas de software Alumno(a): Torres Pulido Myrna Esperanza Fecha: 16 de mayo de 2013 Lugar: Saln S-1
Contenido
3.1 DESCOMPOSICIN MODULAR ...................................................................................................... 3 3.2. PATRONES DE DISEO .................................................................................................................. 8 3.3 ARQUITECTURA DE DOMINIO ESPECFICO .............................................................................. 12 3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR ................................... 16 3.5 DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR ................................. 18 3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA ................................................. 20 3.7 DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL ......................................... 32 BIBLIOGRAFA ....................................................................................................................................... 34
Es una disciplina en proceso de evolucin.
No hay consenso con muchos decisiones de sus conceptos. Existen diferentes interpretaciones de los trminos.
Qu es definicin de modelos?
1
Es la accin de y efecto de modelar configurar a conformar algo no material.
El modelo de negocios se define como un proceso de representacin de uno o ms conceptos de elementos de una empresa, tales como: Sus propsito, su estructura, su funcionalidad, su dinmica su lgico de negocios y sus componentes.
3.1 Descomposicin modular

2
Capacidad de descomposicin modular. Si un mtodo de diseo proporciona
un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva. Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado. Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar. Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios.
1
Trabajo en clases
2 Unidad 6 Diseo y Arquitectura de Software
Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores. Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.
3
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces.
Sus ventajas: Claridad, reduccin de costos y re utilizacin.
Los pasos a seguir son: 1. Identificar los mdulos 2. Describir cada mdulo 3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficiente validad.
1. Independencia funcional
Ingeniera Del Software
Ingeniera de Software 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad
Independencia Funcional
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin
Acoplamiento
El acoplamiento es una medida de la interconexin entre mdulos en la estructura del programa. Se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre los distintos mdulos en que se estructure nuestra aplicacin. El grado de acoplamiento mide la interrelacin entre dos
mdulos, segn el tipo de conexin y la complejidad de la interfaces:
Fuerte
Por contenido, cuando desde un mdulo se puede cambiar datos locales de otro.
Comn, se emplea una zona comn de datos a la que tienen acceso varios mdulos.
Moderado
De control, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio en el formato de datos los afecta a todos.
Dbil
De datos, viene dado por los datos que intercambian los mdulos. Es el mejor.
Sin acoplamiento directo, es el acoplamiento que no existe

5
Cohesin
Un mdulo coherente ejecuta una tarea sencilla en un procedimiento y requiere poca interaccin con procedimientos que se ejecutan en otras partes de un programa. Podemos decir que un mdulo coherente es aquel que
intenta realizar solamente una cosa.
Comprensibilidad
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable:

Identificacin, el nombre debe ser adecuado y descriptivo Documentacin, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo
Adaptabilidad
La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad:
Previsin, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos posibles
Accesibilidad, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su adaptacin
Consistencia, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados.
6
3.2. Patrones de diseo

4
Los patrones de diseo son la base para la bsqueda de soluciones a
problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces.
Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.
Los patrones de diseo pretenden: Proporcionar catlogos de elementos reusables en el diseo de sistemas software. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.
Asimismo, no pretenden: Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrn, siempre teniendo en cuenta
Trabajo en Clases
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".
5
Los patrones de diseo son la base para la bsqueda de soluciones a
problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.
Objetivo De Los Patrones De Diseo Los patrones de diseo pretenden:
Proporcionar catlogos de elementos reusables en el diseo de sistemas software.
Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.
Asimismo, no pretenden:

Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrn, siempre teniendo en cuenta
Ingeniera en software 9
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".
Plantillas O Estructuras De Patrones Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas, si bien la mayora definen los mismos conceptos bsicos. La plantilla ms comn es la utilizada precisamente por el GoF y consta de los siguientes apartados:
Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresan en ingls).
Clasificacin del patrn: creacional, estructural o de comportamiento. Intencin: Qu problema pretende resolver el patrn? Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn.
Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn.
Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes.
Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn.
Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn.
Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn.
10
Patrones relacionados: Referencias cruzadas con otros patrones.
Aplicacin En mbitos Concretos Adems de su aplicacin directa en la construccin de software en general, y derivado precisamente del gran xito que han tenido, los patrones de diseo han sido aplicados a mltiples mbitos concretos producindose "lenguajes de patrones" y extensos "catlogos" de la mano de diversos autores. En particular son notorios los esfuerzos en los siguientes mbitos:
Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-mquina.
Patrones para la construccin de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstraccin importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.
Patrones
para
la
integracin
de
sistemas,
es
decir,
para
la
intercomunicacin y coordinacin de sistemas heterogneos.
Patrones de flujos de trabajo, esto es para la definicin, construccin e integracin de sistemas abstractos de gestin de flujos de trabajo y procesos con sistemas empresariales.
11
3.3 Arquitectura de dominio especfico

6
El reto para el diseo es disear el software y hardware para proporcionar
caractersticas deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos: Arquitectura clienteservidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo tanto, intraorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms adecuadas para la distribucin interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero estn comenzando a usarse para aplicaciones de empresa.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programacin y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representacin de la informacin y los protocolos de comunicacin pueden ser todos diferentes.
Ingeniera Software 12
Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema.
Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computacin distribuida. El middleware es un software de propsito general que normalmente se compra como un componente comercial ms que escribirse especialmente por los desarrolladores de la aplicacin. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicacin.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximacin orientada a objetos. Estos sistemas estn formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.
Existen dos modelos de dominio especfico:
1. Modelos genricos que son abstracciones de varios sistemas reales. 2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.
Modelo genrico: flujo de datos de un compilador Modelo de Referencia: La arquitectura OSI.
13
Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. Arquitecturas de objetos distribuidos.
Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo tanto, intraorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms adecuadas para la distribucin interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios.
Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero estn comenzando a usarse para aplicaciones de empresa. Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programacin y pueden ejecutarse en tipos de procesadores completamente diferentes.
Los modelos de datos, la representacin de la informacin y los protocolos de comunicacin pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computacin distribuida. El middleware es un software de propsito general que normalmente se compra
14
como un componente comercial ms que escribirse especialmente por los desarrolladores de la aplicacin. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicacin. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximacin orientada a objetos.
Estos sistemas estn formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.
15
3.4 Diseo de software de arquitectura multiprocesador

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido.
El multiproceso no es algo difcil de entender: ms procesadores significa ms potencia computacional. Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como estn interconectados dichos
procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al mximo sus prestaciones. La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.
Ventajas Es econmica. El uso de componentes comnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de mquinas con procesadores especialmente diseados (como por ejemplo las mquinas de procesadores vectoriales y de propsito especfico). Adicionalmente, las computadoras paralelas son inherentemente
escalables, permitiendo actualizarlas para adecuarlas a una necesidad creciente. Las arquitecturas tradicionales se actualizan haciendo los procesadores existentes obsoletos por la introduccin de nueva tecnologa a un costo
16
posiblemente elevado. Por otro lado, una arquitectura paralela se puede actualizar en trminos de rendimiento simplemente agregando ms procesadores.
Desventajas
En ocasiones se menciona tambin la limitante fsica; existen factores que limitan la velocidad mxima de un procesador, independientemente del factor econmico.
Barreras fsicas infranqueables, tales como la velocidad de la luz, efectos cunticos al reducir el tamao de los elementos de los procesadores, y problemas causados por fenmenos elctricos a pequeas escalas, restringen la capacidad mxima de un sistema uniprocesador, dejando la opcin obvia de colocar muchos procesadores para realizar clculos cooperativamente.
Es
necesario
conocer
ampliamente
como
estn
interconectados
dichos
procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al mximo sus prestaciones.
17
3.5 Diseo de software de arquitectura Cliente Servidor

7
Este modelo es un prototipo de sistemas distribuidos que muestra como
los datos y el procesamiento se distribuye a lo largo de varios procesadores. Es una forma de dividir las responsabilidades de un sistema de informacin separando la interfaz del usuario de la gestin de la informacin. El funcionamiento bsico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta. Caractersticas de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus caractersticas son: Es quien inicia solicitudes o
peticiones, tienen por tanto un papel activo en la comunicacin (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectase a varios servidores a la vez. Normalmente directamente finales con los una interacta usuarios interfaz
mediante
grfica de usuario. Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus caractersticas son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un papel pasivo en la comunicacin (dispositivo esclavo).
unidad VI Diseo y arquitectura de Software 18
Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al cliente. Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos casos el nmero mximo de peticiones puede estar limitado). No es frecuente que interacten directamente con los usuarios finales.
Ventajas
Centralizacin del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda daar el sistema. Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado. Fcil mantenimiento.
Desventajas La congestin del trfico (a mayor nmero de clientes, ms problemas para el servidor). El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware especfico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentar el costo.
19
3.6 Diseo de software de arquitectura distribuida

8
Un sistema distribuido es un sistema en el que el procesamiento de
informacin se distribuye sobre varias computadoras en vez de estar confinado en una sola mquina. Ventajas: Comparticin de Recursos. Apertura. Concurrencia. Escalabilidad. Tolerancia a Defectos.
La arquitectura de software en ambientes distribuidos proporciona un concepto holstico, que habr que construirse. Describe la estructura y la organizacin de los componentes del software, sus propiedades y la conexin entre ellos. Inconvenientes: Es ms fcil disear y desarrollar el software para el trabajo en paralelo que para una aplicacin nica lineal. Hay que adquirir y aprender un software para las comunicaciones entre los distintos ordenadores. Se necesita un hardware de red de suficiente fiabilidad.
9
Los sistemas distribuidos son comnmente piezas complejas de software
cuyos componentes estn dispersos en mquinas mltiples. Si se desea tener control sobre esta complejidad, es crucial que estos sistemas estn
apropiadamente organizados. La organizacin de los sistemas distribuidos depende mayormente de los componentes de software que constituyen al sistema. Estas arquitecturas de
8 9
Trabajo en clases Clase 03: Arquitecturas de Sistemas Distribuidos
20
software establecen como son organizados varios componentes del software y cmo interactan entre ellos. La implementacin de un sistema distribuido requiere de la divisin e identificacin de los componentes de software y su instalacin en mquinas reales. La implementacin e instalacin final de la arquitectura de software se conoce como arquitectura de software. Como se explic con anterioridad, un objetivo importante de los sistemas distribuidos es separar las aplicaciones de las plataformas subyacentes mediante una capa de middleware. La adopcin de esta capa en una importante decisin arquitectnica, y su principal objetivo es proveer una distribucin transparente de la aplicacin. La transparencia de la distribucin implica en muchos casos la necesidad de hacer ciertos sacrificios o concesiones, por lo que es conveniente que el middleware sea adaptable. Esta adaptabilidad tambin se puede lograr permitiendo que el sistema monitoree su propio comportamiento y que tome las medidas necesarias cuando se requiera. Estos sistemas distribuidos son organizados frecuentemente en la forma de retroalimentacin de control. Estilos Arquitectnicos Para iniciar la discusin sobre arquitecturas, se debe considerar en principio la organizacin de sistemas distribuidos en componentes de software, tambin conocida como arquitectura de software. El estilo arquitectnico est formulado en trminos de componentes, la forma en que estos componentes estn conectados unos con otros y los datos intercambiados entre ellos. Un componente es una unidad modular con interfaces bien definidas, y que puede ser reemplazado en el sistema. Tal vez un trmino ms complejo es el de conector, el cual generalmente es descrito como un mecanismo que media la comunicacin, coordinacin o cooperacin entre componentes. Por ejemplo, un conector puede implementarse mediante RPCs, transferencia de mensajes o flujos de datos.
21
Existen varias configuraciones de componentes y conectores que definen el estilo arquitectnico de un sistema distribuido. Los estilos ms importantes son: Arquitecturas en capas Arquitecturas basadas en objetos Arquitecturas centradas en datos Arquitecturas basadas en eventos
La idea bsica tras el estilo arquitectnico en capas es simple: los componentes estn organizados en forma de capas, en la que un componente en una determinada capa puede llamar a componentes en la capa inmediata inferior. Una observacin clave es que el control generalmente fluye de capa en capa: las peticiones van de arriba abajo y los resultados de abajo a arriba, tal como se puede observar en la Figura 3.1(a). Una organizacin, por mucho ms suelta, se tiene en arquitecturas basadas en objetos, tal como se muestra en la Figura 3.1(b). En esencia, cada objeto corresponde a lo que hemos definido como componente, y estos componentes estn conectados mediante un mecanismo RPC. No es de sorprender que esta arquitectura de software se adapte al modelo cliente-servidor que trataremos ms adelante.
22
Figura 3.1. (a) Estilo arquitectnico en capas; (b) estilo arquitectnico basado en objetos. Las arquitecturas centradas en datos evolucionan en torno a la idea de que los procesos se comunican a travs de un repositorio o medio comn, ya sea pasivo o activo (ver Figura 3.2 (a)). Por ejemplo, una cantidad importante de aplicaciones distribuidas en las que la comunicacin se establece por medio de un archivo compartido a travs de un sistema de archivos distribuidos. En las arquitecturas basadas en eventos, los procesos se comunican esencialmente por medio de la propagacin de eventos, los cuales de manera opcional pueden llevar datos consigo, tal como se muestra en la Figura 3.2 (b). Generalmente, en los sistemas distribuidos, la propagacin de eventos se ha asociado con lo que se conoce como sistemas publicar/subscribir
(publish/subscribe systems). La idea bsica es que los procesos publican eventos tras los cuales el middleware asegura que slo esos procesos que se subscribieron a esos eventos, los recibirn. La ventaja principal de esta arquitectura es que los procesos estn acoplados flojamente. En principio, no se requiere una referencia explcita de proceso a proceso. A esto se le conoce como desacoplamiento en el espacio o referencialmente desacoplados.
Figura 3.2. (a) Arquitectura centrada en datos; (b) arquitectura basada en eventos. Arquitecturas de Sistemas
23
Ya que se ha discutido brevemente sobre algunos estilos arquitectnicos comunes, se ver cmo muchos sistemas distribuidos estn organizados, considerando la manera en que sus componentes de software fueron establecidos. El determinar que componentes de software se usarn, cmo interactuarn y cmo se distribuirn es lo que se conoce como una instancia de arquitectura de software, tambin llamada arquitectura de sistema.
Arquitecturas Centralizadas A pesar de las diferencias en cuanto a varios aspectos de los sistemas distribuidos, solo hay un aspecto en los que muchos expertos coinciden: pensar en trminos de clientes que solicitan servicios a servidores ayuda a entender y administrar la complejidad de los sistemas distribuidos. En el modelo bsico cliente-servidor, los procesos en un sistema distribuido estn divididos en dos grupos, que posiblemente se traslapan. Un servidor es un proceso que implemente un servicio especfico, por ejemplo, un servicio de sistema de archivos distribuido o de base de datos. Un cliente es un proceso que solicita un servicio a un servidor, envindole una peticin y subsecuentemente esperando la respuesta del servidor. La interaccin cliente-servidor, tambin conocida como solicitud-respuesta, se muestra en la Figura 3.3.
Figura 3.3. Interaccin general entre un cliente y un servidor.
24
La comunicacin entre un cliente y un servidor puede ser implementada por medio de un simple protocolo no orientado a la conexin (sin conexin) cuando la red subyacente es suficientemente confiable como es el caso de muchas redes de rea local (LANs). En estos casos, cuando un cliente solicita un servicio, empaca simplemente el mensaje para el servidor, identificando el servicio que requiere y anexando los datos de entrada necesarios. El mensaje es posteriormente enviado al servidor. El servidor se encuentra continuamente en espera de recibir solicitudes, tras lo cual las procesa, empaqueta los resultados en un mensaje de respuesta, y finalmente enva este mensaje al cliente. Implementacin de aplicaciones en capas El modelo cliente-servidor ha sido sujeto de muchos debates y controversias a lo largo de los aos. Una de las principales cuestiones es el cmo establecer una clara distincin entre un cliente y un servidor. No es de sorprender que en muchas ocasiones esta distincin no es tan clara. Por ejemplo, un servidor de una base de datos distribuida a travs de la web puede actuar continuamente como cliente porque ste transfiere las solicitudes a varios servidores de archivos responsables de implementar las tablas de las bases de datos. En este caso, el servidor de base de datos por s mismo no hace ms que procesar las solicitudes de bsqueda o filtrado. La Figura 3.4 muestra este caso.
Figura 3.4. Ejemplo de servidor actuando como cliente.

25
Sin embargo, considerando que muchas aplicaciones cliente-servidor estn orientadas a facilitar al usuario el acceso a la base de datos, mucha gente ha establecido una distincin entre los tres niveles siguientes, esencialmente usando el estilo arquitectnico en capas que se vio previamente: 1. El nivel de interfaz de usuario. 2. El nivel de procesamiento. 3. El nivel de datos. El nivel de interfaz de usuario contiene todo lo necesario para establecer una interfaz directa con el usuario, tal como la administracin del despliegue de la informacin. El nivel de procesamiento tpicamente contiene las aplicaciones. El nivel de datos administra los datos sobre los cuales se est trabajando. Los clientes normalmente implementan el nivel de interfaz de usuario. Este nivel consiste de los programas que permiten al usuario final interactuar con las aplicaciones. Hay una diferencia considerable en que tan sofisticada puede ser una interfaz de usuario. La ms simple no es ms que una simple pantalla de caracteres. Como ejemplo considrese un motor de bsqueda en Internet. La interfaz es muy simple: un usuario introduce una cadena de palabras claves y subsecuentemente se le presenta una lista de ttulos de pginas web. El extremo opuesto de la operacin est constituido por una gran base de datos de pginas web, las cuales han sido extradas e indexadas. El ncleo del motor de bsqueda es un programa que transforma la cadena de palabras claves que proporcion el usuario en una o ms peticiones de bsqueda a la base de datos. Subsecuentemente clasifica los resultados en una lista y transforma esta lista en una serie de pginas HTML. Dentro del modelo cliente-servidor, esta parte de extraccin de informacin es tpicamente localizada en el nivel de procesamiento. La Figura 3.5 muestra esta organizacin.
26
Figura 3.5. Organizacin simplificada en tres niveles diferentes de un motor de bsqueda. Arquitecturas Descentralizadas Las arquitecturas multinivel cliente-servidor, como la del ejemplo del motor de bsqueda mostrado anteriormente, son una consecuencia directa del dividir las aplicaciones en los tres niveles: interfaz de usuario, componentes de procesamiento y datos. Los diferentes niveles corresponden directamente con la organizacin lgica de las aplicaciones. En muchos ambientes, el procesamiento distribuido es equivalente a organizar una aplicacin cliente servidor como una arquitectura multinivel. A este tipo de distribucin se le conoce como distribucin vertical. La caracterstica relevante de una distribucin vertical es que esta puede realizarse disponiendo componentes diferentes mquinas. lgicamente diferentes en mquinas
Una vez ms, desde la perspectiva de administracin
del sistema, el tener una distribucin vertical puede ser una ayuda: las funciones ests lgica y fsicamente divididas y distribuidas en mltiples mquinas, mientras cada mquina est configurada para trabajar ptimamente con un grupo especfico de funciones. Sin embargo, la distribucin vertical es tan solo una manera de organizar aplicaciones cliente-servidor. En arquitecturas modernas, es comn que la
27
distribucin de clientes y servidores sea el factor ms importante, por lo que a este forma de distribucin se le conoce como distribucin horizontal. En este tipo de distribucin, un cliente o un server puede estar fsicamente dividido en partes lgicamente equivalentes, pero cada parte opera con su proprio conjunto integral de datos, balanceando (equilibrando) la carga del sistema. En esta seccin se analizar los sistemas peer-to-peer, una de las arquitecturas modernas que soportan la distribucin horizontal. Un sistema distribuido peer-to-peer (de igual a igual), comnmente abreviado P2P, es una arquitectura compuesta por participantes que ponen a disposicin directa de los otros participantes del sistema parte de sus recursos (poder de procesamiento, almacenamiento de disco, ancho de banda, etc.), sin la necesidad de una instancia de coordinacin central, tales como servidores o hosts permanentes (ver Figura 3.6). Desde una alta perspectiva, los peers (iguales) de un sistema P2P son todos iguales, lo que significa que las funciones que deben ser desarrolladas en el sistema pueden ser realizadas por todo peer participante. En consecuencia, mucha de la interaccin entre los procesos participantes (peers) es simtrica, por lo tanto, los peers pueden ser a la vez tanto proveedores (servidores) como consumidores (clientes).
Figura 3.6. (a) Sistema peer-to-peer (P2P), (b) Sistema centralizado con cervidor
28
Figura 3.8. Principio de operacin de un sistema BitTorrent.
En un sistema BitTorrent para descargar un archivo, el usuario debe tener acceso a un directorio global, el cual es un conjunto de pginas web. Este directorio contiene referencial (enlaces o links) a lo que se conoce como archivos .torrent. Un archivo .torrent contiene la informacin necesaria para descargar un archivo especfico. En particular, se establece una referencia a lo que se conoce como tracker (rastreador), el cual es un servidor que mantiene un registro preciso de todos los nodos activos que tienen partes del archivo deseado. Un nodo activo es aquel que en el momento est descargando otro archivo. Obviamente, habr varios trackers diferentes, aunque generalmente solo habr uno por archivo (o coleccin de archivos). Una vez que los nodos de los que se pueden descargar partes del archivo han sido identificados, el nodo del usuario que desea descargar el archivo, se vuelve activo. En este punto, este nodo ser forzado a ayudar a otros, tal vez proporcionando a otros las partes que an no han obtenido del archivo que se est descargando. Esta regla tiene origen en la siguiente regla: si el nodo P nota que el nodo Q est descargando ms de lo que est distribuyendo ( subiendo) a otros, P puede decidir reducir la velocidad a la que le enva informacin (parte de un archivo, en este caso). Este esquema trabaja bien, siempre que P tenga algo que descargar de Q. Por esta razn, los nodos obtienen referencias a muchos otros nodos, lo cual los sita en una mejor posicin para negociar datos.
29
Ingeniera de Software Arquitectura vs. Middleware
Cuando se consideran los aspectos arquitectnicos que se han considerado hasta el momento, uno debe preguntarse dnde entra el middleware. Como se enseo en clases pasadas, el middleware forma una capa entre las plataformas de
aplicacin y distribucin. Un propsito importante es proveer un cierto nivel de transparencia en la distribucin, ocultando en lo posible la distribucin de datos, el procesamiento y el control de la aplicacin. Lo que comnmente pasa es que el middleware sigue un estilo arquitectnico especfico. Por ejemplo, muchos sistemas de middleware han adoptado un estilo arquitectnico basado en objetos, tales como CORBA; otros, como TIB/Rendeznous, siguen el estilo arquitectnico basado en eventos. El moldear el middleware a un estilo arquitectnico especfico tiene la ventaja de disear aplicaciones ms simples. Sin embargo, una desventaja es que el
middleware puede volverse dejar de ser ptimo para lo que el desarrollador tena en mente. Aunque se supone que el middleware tiene como propsito transparentar la distribucin, generalmente se requiere que el middleware se adapte a las aplicaciones. Una solucin sera desarrollar varias versiones del middleware y otra sera el crear middleware fcilmente configurable y adaptable, segn lo requiera la aplicacin. Autoadministracin en Sistemas Distribuidos Los sistemas distribuidos y el middleware asociado a ellos requieren proveer soluciones generales orientadas a crear un escudo contra condiciones indeseables inherentes a la red, de tal manera que puedan brindar soporte a tantas aplicaciones como sea posible. Los sistemas distribuidos deben ser adaptivos, ms en cuanto a su comportamiento de su ejecucin y no en cuanto a los componentes de software que lo conforman.
30
Cuando se requiere de adaptacin automtica, existe una fuerte interrelacin entre las arquitecturas del sistema y las arquitecturas del software. Por otro lado, se requiere organizar los componentes de un sistema distribuido en tal forma que se pueda implementar el monitoreo y ajuste del sistema; tambin decidir dnde deben ejecutarse los procesos para facilitar la adaptabilidad.
31
3.7 Diseo de software de arquitectura de tiempo real

Los mtodos y herramientas que se usan para construir otros tipos de sistemas no sirven para el software de tiempo real: no son suficientemente fiables. slo contemplan el tiempo de respuesta medio, no el peor. no se garantizan los requisitos temporales.
Las plataformas de desarrollo y ejecucin suelen ser diferentes: es difcil hacer pruebas en la plataforma de ejecucin. es difcil medir los tiempos con precisin.
Niveles de abstraccin Los mtodos de diseo de software comprenden una serie de transformaciones desde los requisitos iniciales hasta el cdigo ejecutable Normalmente se consideran distintos niveles de abstraccin en la descripcin de un sistema: Especificacin de requisitos Diseo arquitectnico Diseo detallado Codificacin Pruebas
Cuanto ms precisa sea la notacin empleada en cada nivel mejor ser la calidad del sistema final.
32
Caractersticas Se descompone en una secuencia de etapas: Hay que completar cada etapa antes de empezar la siguiente.
Las pruebas se llevan a cabo despus de la realizacin: Muchos errores se encuentran slo al final. Volver atrs es muy costoso. A veces se hace sin documentar y de forma poco rigurosa.
Es mejor utilizar un proceso iterativo. Veremos uno centrado en la etapa de diseo. Se trata de validar todos los aspectos que se pueda en la etapa de diseo del sistema. Prestaremos especial atencin a la validacin del comportamiento temporal.
33
Bibliografa
Unidad 6 Diseo y Arquitectura de Software http://radyel.wordpress.com/3/
Ingeniera Del Software http://ederjacielsantos.blogspot.mx/2013/04/31-descomposicion-modular.html Libro Roger Pressman- Ingeniera en sistemas
Unidad VI Diseo y arquitectura de Software http://aniramchaparro.wordpress.com/unidad-vi-karime/
Clase 03: Arquitecturas de Sistemas Distribuidos https://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0 CDEQFjAB&url=https%3A%2F%2Fp8.secure.hostingprod.com%2F%40www.miuni verso.org%2Fssl%2Fgutierrezcasas%2Fefren%2Fuacj%2Fclases%2Fsist_dist%2 Fclase03%2Fclase03.doc&ei=J-aTUfrHHKSMyAGVsYG4DA&usg=AFQjCNHZkq7G66uYFkwzF3zMUI0cnqw4g&sig2=UTpS6O17NEmL1J0OuWYq1A&cad=rja
34

Arquitecturas de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Arquitecturas de Software

Hochgeladen von

Copyright:

Verfügbare Formate

Ingeniera de Software

Instituto tecnolgico de Nogales

Es la accin de y efecto de modelar configurar a conformar algo no material.

3.1 Descomposicin modular

Capacidad de descomposicin modular. Si un mtodo de diseo proporciona

2 Unidad 6 Diseo y Arquitectura de Software

El diseo modular propone dividir el sistema en partes diferenciadas y definir sus

Sus ventajas: Claridad, reduccin de costos y re utilizacin.

Ingeniera Del Software

Ingeniera de Software 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad

Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin

mdulos, segn el tipo de conexin y la complejidad de la interfaces:

Sin acoplamiento directo, es el acoplamiento que no existe

intenta realizar solamente una cosa.

3.2. Patrones de diseo

Los patrones de diseo son la base para la bsqueda de soluciones a

Los patrones de diseo son la base para la bsqueda de soluciones a

Objetivo De Los Patrones De Diseo Los patrones de diseo pretenden:

Proporcionar catlogos de elementos reusables en el diseo de sistemas software.

Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes.

Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn.

Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn.

Patrones relacionados: Referencias cruzadas con otros patrones.

intercomunicacin y coordinacin de sistemas heterogneos.

3.3 Arquitectura de dominio especfico

El reto para el diseo es disear el software y hardware para proporcionar

Existen dos modelos de dominio especfico:

Modelo genrico: flujo de datos de un compilador Modelo de Referencia: La arquitectura OSI.

3.4 Diseo de software de arquitectura multiprocesador

3.5 Diseo de software de arquitectura Cliente Servidor

Este modelo es un prototipo de sistemas distribuidos que muestra como

unidad VI Diseo y arquitectura de Software 18

3.6 Diseo de software de arquitectura distribuida

Un sistema distribuido es un sistema en el que el procesamiento de

Los sistemas distribuidos son comnmente piezas complejas de software

Trabajo en clases Clase 03: Arquitecturas de Sistemas Distribuidos

Figura 3.3. Interaccin general entre un cliente y un servidor.

Figura 3.4. Ejemplo de servidor actuando como cliente.

Una vez ms, desde la perspectiva de administracin

Figura 3.8. Principio de operacin de un sistema BitTorrent.

Ingeniera de Software Arquitectura vs. Middleware

3.7 Diseo de software de arquitectura de tiempo real

Ingeniera Del Software http://ederjacielsantos.blogspot.mx/2013/04/31-descomposicion-modular.html Libro Roger Pressman- Ingeniera en sistemas

Unidad VI Diseo y arquitectura de Software http://aniramchaparro.wordpress.com/unidad-vi-karime/

Das könnte Ihnen auch gefallen