Unidad 3. Arquitectura de Software.

Arquitectura de Software
Definicin: La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones.

3.1 Descomposicin Modular

El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus ventajas: Claridad Reduccin de costos Reutilizacin. 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. a) 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. b) Acoplamiento: Es una medida de la interconexin entre mdulos en la estructura del programa. Podemos graduar en un amplio espectro, pero por lo general se tiene 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 interface: 1. 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. 2. 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. Por etiqueta, en intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, rbol, grafo)

Unidad 3. Arquitectura de Software. 3. Dbil: De datos, viene dado por los datos que intercambian los mdulos. Es el mejor. Sin acoplamiento directo, es el acoplamiento que no existe c) 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. d) 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: 1. Identificacin. El nombre debe ser adecuado y descriptivo 2. Documentacin. Debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo. e) 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: 1. 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 2. 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. 3. Consistencia. Despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados

3.2 Patrones de Diseo

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. Objetivos de los Patrones: 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.

Unidad 3. Arquitectura de Software. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente. 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 que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error". Estructuras o plantillas de patrones: Para describir un patrn se usan plantillas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin entre diseadores. La plantilla ms comn 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. 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: Ejemplo de implementacin del patrn (cdigo fuente). Usos conocidos: Sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones. Existen varios patrones de diseo popularmente conocidos, los cuales se clasifican como se muestra a continuacin: a) Patrones Creacionales: Inicializacin y configuracin de objetos. b) Patrones Estructurales: Separan la interfaz de la implementacin. Se ocupan de cmo las clases y objetos se agrupan, para formar estructuras ms grandes. c) Patrones de Comportamiento: Ms que describir objetos o clases, describen la comunicacin entre ellos.

3.3 Arquitectura de Dominio Especfico

Son abstracciones sobre un dominio de aplicacin. Se trata de estructuras arquitectnicas comunes que se reutilizan cuando se desarrollan nuevos sistemas que difieren en detalles de los anteriormente implementados.

Unidad 3. Arquitectura de Software.

Existen dos modelos de dominio especfico: 1. Modelos genricos: Son abstracciones de varios sistemas reales que encapsulan las caractersticas principales de estos sistemas. Se pueden utilizar directamente en el diseo. Se derivan de forma ascendente a partir de los sistemas existentes. Pocos modelos genricos estn disponibles al pblico; las organizaciones que desarrollan estos modelos los ven como una propiedad intelectual necesaria para el desarrollo de futuros sistemas. Ejemplo: Un modelo de Compilador es un ejemplo conocido a travs de otros modelos que existen en dominios de aplicaciones especializadas 2. Modelos de referencia: Son modelos abstractos. Proveen un medio de informacin acerca de cada clase de sistema y permiten comparar diversas arquitecturas. Se utilizan para comunicar conceptos del dominio y comparar las posibles arquitecturas. Se derivan de forma descendente. Algunos patrones de diseo se consideran como arquitecturas de referencia que proporcionan un vocabulario para realizar comparaciones Ejemplo: El modelo OSI (Interconexin de Sistemas Abiertos) es un modelo en capas para sistemas de comunicacin

3.4 Diseo de Software de Arquitectura Multiprocesador.

Un sistema operativo multiproceso se refiere al nmero de procesadores del sistema, que es ms de uno y ste es capaz de usarlos todos para distribuir su carga de trabajo. Es tradicionalmente conocido como el uso de mltiples procesos concurrentes en un sistema en lugar de un nico proceso en un instante determinado. Como la multitarea que permite a mltiples procesos compartir una nica CPU, mltiples CPUs pueden ser utilizados para ejecutar mltiples hilos dentro de un nico proceso. 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. 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 COMPUTADORAS CON MULTIPROCESADORES IBM DEEP BLUE Deep Blue fue una computadora de IBM que jugaba al ajedrez. Su nombre se podra traducir al espaol como "Azul Profundo".

Unidad 3. Arquitectura de Software. Se emplea un algoritmo de inteligencia artificial de la familia Minimax. La fuerza de juego de estos programas de juego automtico es mayor cuanto mayor sea la profundidad (nmero de movimientos futuros) hasta la que llega la exploracin, y por tanto mayor el nmero de nodos. El sistema saca su fuerza de juego principalmente en la fuerza bruta que calcula el sistema central. Era una potencia paralela, de 30 nodos, RS/6000, SP-based el sistema informtico realzado (mejorado) con 480 VLSI con el objetivo especial de jugar al ajedrez. Era capaz de calcular 200 millones de posiciones por segundo, dos veces ms rpido que la versin de 1996. En junio de 1997, Deep Blue era el 259 superordenador ms poderoso, capaz de calcular 11.38 gigaflops, aunque toda esta potencia no estaba pensada en realidad para jugar al ajedrez.

SUPER COMPUTADORA CRAY La supercomputadora Cray XD1 combina sistemas avanzados de interconexin, administracin y tecnologa computacional reconfigurable que satisface de manera confiable las demandas de procesamiento de alto rendimiento. Diseada para cumplir con los requerimientos de cmputo de alto rendimiento (HPC) en reas que van del diseo de productos, a prediccin del clima, e investigaciones cientficas. La Cray XD 1 es una poderosa herramienta para cientficos e ingenieros que les permite simular y analizar problemas de mayor complejidad de forma rpida. La Cray XD 1 est basada en la arquitectura de "Conexin Directa entre Procesadores (DCP)" lo que permite interconectar muchos procesadores como uno solo, optimizando las aplicaciones que hacen uso del envo de mensajes, enlazando un bloque de procesadores al siguiente a travs de interconexiones (propietarias) de alto desempeo, eliminando la contencin de la memoria compartida y de los cuellos de botella en los dispositivos PCI. Las caractersticas del equipo son las siguientes: 216 Procesadores AMD Opteron 275, x8664, 2.2 GHzz 216 Gbytes DDR 400 registered ECC de memoria RAM Total 4 Tbytes de almacenamiento principal 1 Tbyte de registros de memoria accesibles por procesador Interconexion tipo Rapid Array Interconnect 1.7 s Latencia MPI entre procesadores Rendimiento Terico Pico 0.95TFlops

3.5 Diseo de Software de Arquitectura Cliente-Servidor

La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un Sistema de Informacin separando la interfaz de usuario (Nivel de presentacin) de la gestin de la informacin (Nivel de gestin de datos). Esta arquitectura consiste bsicamente en que un programa, el Cliente informtico realiza peticiones a otro programa, el servidor, que les da respuesta La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no hay distribucin, tanto a nivel fsico como a nivel lgico.

Unidad 3. Arquitectura de Software. Cliente: En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Caractersticas: 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. Servidor: Caractersticas de un servidor en los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Caractersticas: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un papel pasivo en la comunicacin (dispositivo esclavo). 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 del Diseo de Software de Arquitectura Cliente-Servidor: 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. Se reduce el trfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstraccin como por ejemplo SQL. Desventajas del Diseo de Software de Arquitectura Cliente-Servidor: 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

3.6 Distribucin de Software de Arquitectura Distribuida

Un sistema distribuido es un sistema de informacin en el cual las funciones se reparten por reas de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la organizacin asigna a ese sistema de informacin. Disear un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudndose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotndolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido.

Unidad 3. Arquitectura de Software. La plataforma de proceso. Una vez diseado el sistema, es el elemento encargado de proporcionar los recursos fsicos y el software de base para ejecutarlo. Est formado por los Mainframe, PCs, PDAs, telfonos, etc Los elementos de la conectividad. Son los encargados se proporcionar el transporte para comunicar e integrar los elementos de la plataforma de proceso. Son bsicamente las redes y las comunicaciones. El almacenamiento de datos, formado por los datos en s y los gestores donde se localizan. Los elementos de software, donde se incluyen las aplicaciones, los servicios que ayudan a crearlas y las interfaces que ayudan a usarlas. En este componente se integran las arquitecturas posibles para crearlas: centralizada, Batch, transaccional, cliente/servidor basado en sistema operativo, cliente/servidor basada en Internet y aplicaciones Web Internet. Los sistemas distribuidos que se diseen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compaa y permitir el mayor rendimiento con el menor coste en las estructuras informticas que dan soporte.

3.7 Diseo de Software de Arquitectura de Tiempo Real

El software de tiempo real debe, operar bajo restricciones de rendimiento muy rigurosas, el diseo del software est conducido frecuentemente, tanto por la arquitectura del hardware como por la del software. Un sistema de tiempo real es un sistema software cuyo correcto funcionamiento depende de los resultados producidos por el mismo y del instante del tiempo en el que se producen estos resultados. Un sistema de tiempo real blando (soft) es un sistema cuyo funcionamiento se degrada si los resultados no se producen de acuerdo con los requerimientos temporales especificados. Una forma de ver un sistema de tiempo real es como un sistema de estmulo/respuesta. Dando un determinado estimulo de entrada, el sistema debe producir la correspondiente salida. Se define el comportamiento de un sistema de tiempo real haciendo una lista de los estmulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas deben producirse. Los estmulos pueden pertenecer a dos clases: 1. Estmulos peridicos. Ocurren a intervalos de tiempo predecibles. Los estmulos peridicos en un sistema de tiempo real son generados normalmente por sensores asociados al sistema. Estos proporcionan informacin sobre el estado del entorno del sistema. Las respuestas son dirigidas a un conjunto de actuadores que controlan algn equipo como una bomba, que influye en el entorno del sistema. 2. Estmulos aperidicos. Ocurren de forma regular. Los estmulos aperidicos pueden generarse por actuadores o por sensores. A menudo indican alguna condicin excepcional como un fallo en el hardware, que debe ser manejado por el sistema.