1. ARQUITECTURA DE SOFTWARE

En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entraaba para la mayora de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guas generales, con base a las cuales se puedan resolver los problemas.

A estas guas o formas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construccin, estas indican la estructura, funcionamiento e interaccin entre las partes del software.En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseo que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema".

1.1. DefinicinExisten diversas definiciones de arquitectura de software, sin embargo las mas acertadas probablemente sean las siguientes: La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema. Una Arquitectura de Software, tambin denominada Arquitectura lgica, es aquella que consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de trabajo a seguir.

1.2. ObjetivosUna arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como lo son:1. Mantenibilidad2. Auditabilidad3. Flexibilidad4. Interaccin con otros sistemas de informacin

1.3. RestriccionesLas restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin.En ocasiones algunas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas.Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.

3.1 DESCOMPOSICIN MODULAR

La descomposicin modular es 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 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:Es aquella que permite que un mtodo de diseo, ensamble componentes de diseo (reusables) existentes en un sistema nuevo, produciendo as 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.

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.

El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reduccin de costos y 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.

1. Independencia funcional

2. Acoplamiento

3. Cohesin

4. Comprensibilidad

5. Adaptabilidad

3.2 PATRONES DE DISEO

Lospatrones de diseoson 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 suefectividadresolviendo problemas similares en ocasiones anteriores. Otra es que debe serreutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.

Objetivos 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 que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Categoras de patrones de diseo

Segn la escala o nivel de abstraccin:

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software. Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas de software. Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto.Adems, tambin es importante resear el concepto de "antipatrn de diseo", que con forma semejante a la de un patrn, intenta prevenir contra errores comunes de diseo en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseos muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejn sin salida por haber cometido los mismos errores.

Adems de los patrones ya vistos actualmente existen otros patrones como el siguiente:

Interaccin: Son patrones que nos permiten el diseo de interfaces web.3.3 ARQUITECTURA DE MODELO ESPECIFICO

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 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 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

3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR

Los sistemas multiprocesador (MP) son un tipo de arquitectura con una importancia creciente y ampliamente difundido. La mayora de los constructores de computadores ofrece mquinas en las que estn presentes ms de una CPU, configuracin que es hoy en da de uso habitual en casi todos los sistemas de tamao medio y grande, incluso ya en ordenadores personales.

Asimismo, los fabricantes de procesadores incorporan a sus arquitecturas, desde hace unos aos, los mecanismos necesarios para que stos se puedan emplear fcilmente, y con un coste reducido (publicidad de Sun Microsystems en 1999: "si compra un procesador, le regalamos otro"), en la construccin de este tipo de sistemas.

Esta tendencia se ha visto reforzada en los ltimos aos con la aparicin de los multicore, es decir, varios ncleos por procesador. En los prximos aos veremos mquinas con bastantes procesadores, cada uno de ellos con multitud de ncleos. Por tanto, comprender como funcionan y saber explotar correctamente esta potencia de cmputo se vuelve algo necesario para cualquier ingeniero informtico.

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 solo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultanea varios procesos es tener varias cpus ya sea en una maquina o en varias en un sistema distribuido.

La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto y 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 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.

VENTAJAS

Es econmica

Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para adecuarse a la necesidad

DESVENTAJAS

Puede ser limitante fsica, existen factores que limitan la velocidad mxima de un procesador independiente del factor econmico

Las barreras fsicas infranqueables tales como la velocidad de la luz, efectos de tamao, la capacidad.

3.5 DISEO DE SOFTWARE DE CLIENTE SERVIDOR

Laarquitectura cliente-servidores un modelo de aplicacin distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea tambin se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es ms ventajosa en un sistema operativo multiusuario distribuido a travs de una red de computadoras.

En esta arquitectura la capacidad de proceso est repartida entre los clientes y los servidores, aunque son ms importantes las ventajas de tipo organizativo debidas a la centralizacin de la gestin de la informacin y la separacin de responsabilidades, lo que facilita y clarifica el diseo del sistema.

La separacin entre cliente y servidor es una separacin de tipo lgico, donde el servidor no se ejecuta necesariamente sobre una sola mquina ni es necesariamente un slo programa. Los tipos especficos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propsitos varan de unos servicios a otros, la arquitectura bsica seguir siendo la misma.

Una disposicin muy comn son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentescomputadorasaumentando as el grado de distribucin del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no hay distribucin, tanto a nivel fsico como a nivel lgico.

La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes estn conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposicin de los clientes cada vez que estos son solicitados.

Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en l se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso pblico y los que son de uso restringido, los archivos que son de slo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta.

Caractersticas

En la arquitectura C/S elremitente de una solicitudes conocido como cliente. Sus caractersticas son:

Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicacin (dispositivomaestrooamo). Espera y recibe las respuestas del servidor. Por lo general, puede conectarse a varios servidores a la vez. Normalmente interacta directamente con los usuarios finales mediante una interfaz grfica de usuario. Al contratar un servicio de redes, se debe tener en cuenta la velocidad de conexin que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA

La utilizacin de la arquitectura distribuida basada en una red de ordenadores personales tiene como objetivo global: obtener prestaciones razonables a un coste bajo.

VENTAJAS DE LA ARQUITECTURA DISTRIBUIDA

Fue creada a partir de la Arquitectura n-Layer desacoplada, donde intervienen las capas de presentacin, de negocio, de servicios y datos. Adems de las tecnologas para su implementacin, Workflows, Servicios Web e Interfaces Grficas declarativas. En la siguiente grafica se muestran las capas que la conforman.

Evita la sobrecarga de procesador con clculos sobre los modelos matemticos y generacin de la escena.

Permite una mayor reutilizacin del cdigo: al ser compartimentos ms o menos estancos, las mayores variaciones se realizan en interfase de usuario.

El uso de ordenadores personales reduce el coste inicial de implantacin.

Los ordenadores personales son altamente fiables, se reparan fcilmente y se sustituyen de forma inmediata.

Es software empleado es de gran difusin y se encuentra fcilmente software desarrollado y personal cualificado.

El uso del mismo tipo de ordenador para tareas distintas permite un coste de mantenimiento ms reducido.

Inconvenientes de la arquitectura distribuida:

Es ms difcil disear y desarrollar el software para el trabajo en paralelo que para una aplicacin nica lineal.

Hay adquirir y aprender un software para las comunicaciones entre los distintos ordenadores.

Los problemas de organizacin del trfico de informacin para garantizar la consistencia de las comunicaciones es una tarea bien compleja.

Se necesita un hardware de red de suficiente fiabilidad.

La depuracin de los programas en este tipo de arquitectura se dificulta enormemente. En algunos casos es necesario desarrollar herramientas ad-hoc para obtener datos que puedan ayudar a la depuracin.

3.7 DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL ARQUITECTURA

Un sistema de tiempo real es un sistema de procesamiento de informacin el cual tiene que responder a estmulos de entrada generados externamente en un perodo finito y especfico.

Un sistema en tiempo real es una combinacin de computadoras, dispositivos de E/S, hardware y software de propsito especfico en donde:

existe una fuerte interaccin con el ambiente. el ambiente cambia con el tiempo el sistema debe controlar y/o reaccionar a diferentes aspectos del ambiente.Como resultado:

Se imponen restricciones de tiempos al software. El software es naturalmente concurrente. Se exige una alta confiabilidad.Una caracterstica distintiva de un sistema en tiempo real es la predecibilidad. La cual implica que debe ser posible demostrar o comprobar a priori que los requerimientos de tiempos se cumplen en cualquier circunstancia.

TAREAS

Los Sistemas de Tiempo Real ejecutan actividades oTareas

En un intervalo de tiempo predeterminado. Tienen varios tipos de propiedades: Funcionales: qu hacen.

Temporales: cundo lo hacen. El comportamiento temporal de las tareas se especifica mediante sus atributos temporales:

Cundo se ejecutan: esquema de activacin.

Qu plazo tienen para ejecutar cada accin

http://incytde.org/incytde/node/86http://www.tec.url.edu.gt/boletin/URL_19_SIS11_SOFTWARE.pdfhttp://es.slideshare.net/jdbg16/ingenieria-de-software-un-enfoque-prctico-pressman-5th-edhttp://www.academia.edu/6281807/Ingenieria_del_Software._Un_Enfoque_Practicohttp://arq1software.blogspot.mx/2009/12/componentes-de-software.htmlhttp://ithroshuejutla.blogspot.mx/https://radyel.wordpress.com/3/https://arquitecturacomp.wordpress.com/2009/07/13/sistemas-multiprocesadores/