Instituto tecnolgico superior de Coatzacoalcos

Alumnos: Caligua Ortiz Carlos Alberto. Catedrtico: Castilla Acosta Karla Margarita. Materia: Fundamento de desarrollo de sistemas. Unidad 6 Diseo y arquitectura de proyectos de software. Actividad: Investigacin unidad 6 Grado y grupo: 6 B COATZACOALCOS, VER A 27 DE JUNIO DEL 2011

INTRODUCCION
EN LA PRESENTE UNIDAD ABORDAREMOS LOS TEMAS RELACIONADOS CON LAS ARQUITECTURAS DE COMPUTADORAS Y SUS DIVERSAS CARIEDADES O TIPO, COMO LA DE CLIENTE SERVIDOR, O LA DE MULTIPROCESAMIENTO Y LOS SISTEMAS DISTRIBUIDOS Y LOS DE TIEMPO REAL.

OBJETIVOS
COMPRENDERA LAS ARQUITECTURAS EN EL DISEO DE SOFTWARE DEPENDIENDO DEL TIPO DE DOMINIO DE LA APLICACIN.

6.1 Descomposicin modular. El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reduccin de costos y reutilizacion Los pasos a seguir son: 1. Identificar los mdulos 2. Describir cada mdulo 3. Describir las relaciones entre mdulos Una descomposicion modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficiente vlidad. 1. Independencia funcional 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad 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 El acoplamiento es un medida de la interconexin entre mdulos en la estructura del programa. Podemos graduara en un amplio espectro, pero por lo general se tiede a que el acopl amiento sea lo menor posible, esto es a reduir 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 inter fase: . 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 estan l igados los mdulos, esto implica que un cambio en el formato de datos los afecta a todos. - Por etiqueta, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, rbol,grafo,) . 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 de sw 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. Para que n de mdulos no sea demaciado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo. ALTA . Cohesionabstraccional, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos . Cohesin funcional, el mdulo realiza una funcin concreta y especfica MEDIA . Cohesin secuencial, los elementos del mdulo trabajan de forma secuencial . Cohesin de comunicacin, elementos que operan con el mismo conjunto de datos de entrada o de salida . Cohesin temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej.Arrancar o parar dispositivos BAJA . Cohesin lgica, se agrupan elementos que realizan funciones similares.

. Cohesin coincidental, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin: - Si es una frase compuesta y cotiene ms de un verbo la cohesin ser MEDIA - Si contiene expreciones secuenciales (primero, entonces, cuando), ser temporal o secuencial - Si la descripcion no se refiere a algo especifico(Ej. Todos los errores), cohesin lgica - Si aparece inicializar, preparar, configurar, probablemente sea temporal. d) Comprensibilidad Para facilitar los cambios, el mantenimiento y la reutilizacin de md ulos 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 - SIMPLICIDAD, las soluciones sencillas son siempre laas mejores e) Adaptabilidad La adaptacin de un sistema resulta ms dificil cuando no hay idependencia 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 suseptibles 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 siste ma antes de proceder a su adaptacin - Consistencia, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados Arquitectura del software La Arquitectura de Software(As) constituye una disiplinadde reciente aparicin y forma parte del paradigma de la Ingenieria del Software. . Representa la versin moderna de un diseo software y es apta para describir sistemas complejos. Definicion: Arquitectura de Software Una arquitectura de software es un conju nto de elementos arquitectnicos que tiene una determinada forma. Las propiedades restringen la eleccin de los elementos de la arquitectura mientras que la lgica captura la motivacin de la eleccin de los elemetos y la forma. (Perry y Wolf 1992) Una arquitectura de software incluye la descripcin de elementos a partir de los cuales se constituyen los sistemas de software, interacciones entre esos elementos, patrones que guan la composicin y restricciones sobre esos patrones. En general, un sistema de software particular se define en trminos de una coleccin de componentes e interacciones entre dichos componentes. Tal sistema puede ser utilizado como un elemento en un sistema ms grande.(Garlan y Shaw 1996) Una arquitectura de software de un program a o sistema de computacin es la estructura o estructuras del sistema, el cual comprende componentes, las propiedades visibles externas de dichos componentes y las relaciones entre ellos.(Bass, Clements y Kazman 1998). 6.2 arquitectura de dominio especifi co. 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 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 fo rma 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 ha y 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 servici os. 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 (Ber nstein, 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 desarrolladore s 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 utiliza ndo 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 pue den tener que responder a eventos independientes. Los objetos software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos. 6.2.1 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 vario s procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido. 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. 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. Para lograrlo, es necesario modificar varias facetas del sistema operat ivo, la organizacin del cdigo de las propias aplicaciones, as como los lenguajes de programacin. Se configuran dos computadoras de gran capacidad interconectados electrnicamente entre si. Esta configuracin recibe el nombre de multiproceso y se caract eriza porque permite proceso de datos continuo an en el caso de que surjan problemas de funcionamiento en alguno de las computadoras.

Un ejemplo de este tipo de sistema se muestra en la figura 6.3. ste es un modelo sencillo de un sistema de control de trfico areo. Un conjunto de sensores distribuidos recolecta la informacin del flujo de trfico y la procesa localmente antes de enviarla al cuarto de control. Los operadores toman decisiones utilizando esta informacin y dan instrucciones a un proceso de control de diversas luces de trfico. En este ejemplo existen varios procesos lgicos para administrar los sensores, el cuarto de control y las luces de trfico. Estos procesos lgicos son procesos sencillos a un grupo de procesos. En este ejemplo se ejecu tan en procesadores diferentes. Los sistemas de software compuestos de procesos mltiples no necesariamente son sistemas distribuidos. Si ms de un procesador est disponible, entonces se puede implementar la distribucin, pero los diseadores del sistema no siempre consideran lo puntos de distribucin durante el proceso de diseo. El enfoque de diseo para este tipo de sistemas es esencialmente el mismo que para los de tiempo real. 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 cost o 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 velo cidad 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 sistem a uniprocesador, dejando la opcin obvia de colocar muchos procesadores para realizar clculos cooperativamente. 6.2.2 diseo de software de arquitectura cliente/servidor. Modelo Cliente / Servidor: Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Es una forma de dividir las responsabilidades de un sistema de informacin separando la interfaz del usuari o 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 r emitente 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 interacta directamente con los usuarios finales mediante una interfaz grfica de usuario. Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada por cli ente 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). Tras la recepcin de una solicitud, la procesan y l uego 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 6.2.3 diseo de software distribuido. 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 informaci n.

Elementos de un sistema Distribuido En l se integran. 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. Esta 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 si y los gestores donde se localizan. Los elementos de software donde se incluyen las aplicaciones, los servicios que ayudan a crearlas y las interfcies 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. A lo largo de la exposicin pondremos especial cuidado en presentar las caractersticas y posibilidades las tres ltimas. Sistemas de seguridad. Finalmente, debe realizarse la gestin del sistema como un conjunto integrado y coordinado a travs de los recursos de direccin y administracin. La gestin del sistema debe permitir la coexistencia de varios centros de gestin diferentes. Parte fundamental del sistema de gestin es el cuadro de mandos. Hay dos cuadros de mandos diferentes: El cuadro de mandos de seguimiento de los objetivos de negocio pensado para proporcionar informacin automtica a los gestores de como la realidad se mueve respecto a las previsiones de los objetivos de negocio en tiempo real. El cuadro de mandos de explotacin desde donde se centraliza y coordina toda la administracin, supervisin y expl otacin del sistema. 6.2.4 diseo de software de tiempo real. El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las caractersticas del sistema

operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin .

CONCLUSION
COMO NOS DIMOS CUENTA CADA TIPO DE ARQUITECTURA SE DEBE ELEGIR DEPENDIENDO DE EL TIPO DE DOMINIO DE LA APLICACIN, ES DECIR, HACIA QUE AREA VA DIRIGIDA, YA SEA PARA EL DE CLIENTE SERVIDOR O MULTIPROCESADOR.