3.1 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.2 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.3 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.
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 diferentes computadoras 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
A los sistemas de tiempo real también se les
conoce como sistemas empotrados o embebidos. Es un sistema informático que interacciona rápidamente con su entorno físico y realiza funciones de supervision y control.
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
