ARQUITECTURA DE SOFTWARE
En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas.
A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción 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 diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".
- La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
- Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
- Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías 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 computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.
3.1 DESCOMPOSICIÓN MODULAR
Capacidad de empleo de componentes modulares. Si un método de diseño permite ensamblar los componentes de diseño (reusables) existentes en un sistema nuevo, producirá una solución modular que no inventa nada ya inventado.
Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar.
Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios.
Protección modular. Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede diseñar modularmente, incluso aunque su implementación deba ser «monolítica». 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 mínimos que sean (por ejemplo, subrutinas, procedimientos).
Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar.
Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios.
Protección modular. Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede diseñar modularmente, incluso aunque su implementación deba ser «monolítica». 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 mínimos que sean (por ejemplo, subrutinas, procedimientos).
En tales situaciones el software podrá y deberá diseñarse con modularidad como filosofía predominante.
El código se puede desarrollar «en línea». Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular.
El código se puede desarrollar «en línea». Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular.
El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reducción de costos y reutilización.
Los pasos a seguir son:
1. Identificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesión
4. Comprensibilidad
5. Adaptabilidad
3.2 PATRONES DE DISEÑO
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. 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 diseño en distintas circunstancias.
Objetivos de los patrones de diseño
Los patrones de diseño pretenden:
· Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
· Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
· Formalizar un vocabulario común entre diseñadores.
· Estandarizar el modo en que se realiza el diseño.
· Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
· Imponer ciertas alternativas de diseño frente a otras.
· Eliminar la creatividad inherente al proceso de diseño.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, 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".
Categorías de patrones de diseño
Según la escala o nivel de abstracción:
· Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.
· Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
· Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.
Además, también es importante reseñar el concepto de "antipatrón de diseño", que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.
Además de los patrones ya vistos actualmente existen otros patrones como el siguiente:
· Interacción: Son patrones que nos permiten el diseño de interfaces web.
3.3 ARQUITECTURA DE MODELO ESPECIFICO
El reto para el diseño es diseñar el software y hardware para proporcionar características 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 genéricos 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 distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución 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 están comenzando a usarse para aplicaciones de empresa.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación 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 término 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 computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están 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 características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.
Existen dos modelos de dominio específico:
• 1. Modelos genéricos que son abstracciones de varios sistemas reales.
• 2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.
Modelo genérico: flujo de datos de un compilador
Modelo de referencia: la arquitectura OSI
3.4 DISEÑO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR
Los sistemas multiprocesador (MP) son un tipo de arquitectura con una importancia creciente y ampliamente difundido. La mayoría de los constructores de computadores ofrece máquinas en las que están presentes más de una CPU, configuración que es hoy en día de uso habitual en casi todos los sistemas de tamaño medio y grande, incluso ya en ordenadores personales.
Asimismo, los fabricantes de procesadores incorporan a sus arquitecturas, desde hace unos años, los mecanismos necesarios para que éstos se puedan emplear fácilmente, y con un coste reducido (publicidad de Sun Microsystems en 1999: "si compra un procesador, le regalamos otro"), en la construcción de este tipo de sistemas.
Esta tendencia se ha visto reforzada en los últimos años con la aparición de los multicore, es decir, varios núcleos por procesador. En los próximos años veremos máquinas con bastantes procesadores, cada uno de ellos con multitud de núcleos. Por tanto, comprender como funcionan y saber explotar correctamente esta potencia de cómputo se vuelve algo necesario para cualquier ingeniero informático.
Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las cpu´s solo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultanea varios procesos es tener varias cpu´s ya sea en una maquina o en varias en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operación 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 difícil de entender: más procesadores significa más potencia computacional.
Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo.
VENTAJAS
Es económica
Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para adecuarse a la necesidad
DESVENTAJAS
Puede ser limitante física, existen factores que limitan la velocidad máxima de un procesador independiente del factor económico
Las barreras físicas infranqueables tales como la velocidad de la luz, efectos de tamaño, la capacidad.
3.5 DISEÑO DE SOFTWARE DE CLIENTE – SERVIDOR
La arquitectura cliente-servidor es un modelo de aplicación 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 también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentescomputadoras aumentando así el grado de distribución del sistema.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.
La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición 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 público y los que son de uso restringido, los archivos que son de sólo 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.
Características
En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:
· Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
· Espera y recibe las respuestas del servidor.
· Por lo general, puede conectarse a varios servidores a la vez.
· Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.
· Al contratar un servicio de redes, se debe tener en cuenta la velocidad de conexión 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 DISEÑO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA
La utilización 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 presentación, de negocio, de servicios y datos. Además de las tecnologías para su implementación, Workflows, Servicios Web e Interfaces Gráficas declarativas. En la siguiente grafica se muestran las capas que la conforman.
• Evita la sobrecarga de procesador con cálculos sobre los modelos matemáticos y generación de la escena.
• Permite una mayor reutilización del código: al ser compartimentos más o menos estancos, las mayores variaciones se realizan en interfase de usuario.
• El uso de ordenadores personales reduce el coste inicial de implantación.
• Los ordenadores personales son altamente fiables, se reparan fácilmente y se sustituyen de forma inmediata.
• Es software empleado es de gran difusión y se encuentra fácilmente software desarrollado y personal cualificado.
• El uso del mismo tipo de ordenador para tareas distintas permite un coste de mantenimiento más reducido.
Inconvenientes de la arquitectura distribuida:
• Es más difícil diseñar y desarrollar el software para el trabajo en paralelo que para una aplicación única lineal.
• Hay adquirir y aprender un software para las comunicaciones entre los distintos ordenadores.
• Los problemas de organización del tráfico de información para garantizar la consistencia de las comunicaciones es una tarea bien compleja.
• Se necesita un hardware de red de suficiente fiabilidad.
• La depuración 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 depuración.
3.7 DISEÑO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL ARQUITECTURA
Un sistema de tiempo real es un sistema de procesamiento de información el cual tiene que responder a estímulos de entrada generados externamente en un período finito y específico.
Un sistema en tiempo real es una combinación de computadoras, dispositivos de E/S, hardware y software de propósito específico en donde:
· existe una fuerte interacción 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 característica 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 o
Tareas
En un intervalo de tiempo predeterminado. Tienen varios tipos de propiedades:
• Funcionales: qué hacen.
• Temporales: cuándo lo hacen. El comportamiento temporal de las tareas se especifica mediante sus atributos temporales:
• Cuándo se ejecutan: esquema de activación.
• Qué plazo tienen para ejecutar cada acción
