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 introducción 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.
3 .2 Patrón 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
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
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.
Estructuras o
plantillas de patrones
Para
describir un patrón se usan plantillas más o menos estandarizadas, de forma que
se expresen uniformemente y puedan constituir efectivamente un medio de
comunicación uniforme entre diseñadores. Varios autores eminentes en esta área
han propuesto plantillas ligeramente distintas, si bien la mayoría definen los
mismos conceptos básicos.
La
plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:
- Nombre del
patrón: nombre
estándar del patrón por el cual será reconocido en la comunidad
(normalmente se expresan en inglés).
- Clasificación
del patrón:
creacional, estructural o de comportamiento.
- Intención: ¿Qué problema pretende resolver el
patrón?
- También
conocido como: Otros
nombres de uso común para el patrón.
- Motivación: Escenario de ejemplo para la
aplicación del patrón.
- Aplicabilidad: Usos comunes y criterios de
aplicabilidad del patrón.
- Estructura: Diagramas de clases oportunos para
describir las clases que intervienen en el patrón.
- Participantes: Enumeración y descripción de las
entidades abstractas (y sus roles) que participan en el patrón.
- Colaboraciones: Explicación de las interrelaciones
que se dan entre los participantes.
- Consecuencias: Consecuencias positivas y negativas
en el diseño derivadas de la aplicación del patrón.
- Implementación: Técnicas o comentarios oportunos de
cara a la implementación del patrón.
- Código de
ejemplo: Código
fuente ejemplo de implementación del patrón.
- Usos conocidos: Ejemplos de sistemas reales que usan
el patrón.
- Patrones
relacionados:
Referencias cruzadas con otros patrones.
3.3
Arquitectura de dominio 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 Software Arquitectura Multiprocesador
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 sólo pueden ejecutar un
proceso cada vez. La única forma de que se ejecuten de forma simultánea varios
procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un
sistema distribuido.
La ventaja de un sistema
multiproceso reside en la operación llamada cambio de contexto. Esta operación
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
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. Esa es la teoría, pero otra historia es
la práctica, como hacer funcionar el multiproceso, lo que requiere unos
profundos conocimientos tanto del hardware como del software.
Es necesario conocer ampliamente
como están interconectados dichos procesadores, y la forma en que el código que
se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software
que aproveche al máximo sus prestaciones.
3.5 Diseño Software
Arquitectura Cliente-Servidor
La arquitectura cliente-servidor
es una forma de dividir las responsabilidades de un Sistema de Información
separando la interfaz de usuario (Nivel de presentación) de la gestión de la
información (Nivel de gestión de datos).
Esta arquitectura consiste
básicamente en que un programa, el Cliente informático realiza peticiones a
otro programa, el servidor, que les da respuesta.
Aunque esta idea se puede aplicar
a programas que se ejecutan sobre una sola computadora es más ventajosa en un
sistema multiusuario distribuido a través de una red de computadoras.
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.
Ventajas de la arquitectura
cliente-servidor
› Centralización 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 dañar el
sistema.
› Escalabilidad: se puede
aumentar la capacidad de clientes y servidores por separado.
Se reduce el tráfico de red
considerablemente. Idealmente, el cliente se comunica con el servidor
utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL.
3.6
Diseño Software Distribuido
Estos recursos técnicos suelen
catalogarse en:
- Infraestructura.
-Plataforma.
-Comunicaciones.
-Datos.
- Software:
- Aplicaciones.
-Interfícies.
-Servicios.
- Seguridad.
Pero no olvidemos que detrás del
sistema operativo hay personas que lo usan y los gestionan. El factor humano
será fundamental como nos cuidaremos de recordar a lo largo del todo el diseño.
Diseñar un sistema distribuido es
crear aplicaciones de software que, utilizando servicios y ayudándose de la
conectividad, participen y se integren en este entorno de forma transparente a
las plataformas de proceso y de almacenamiento de datos, dotándolas de los
recursos necesarios para gestionarse de forma integrada con el resto del
sistema distribuido.
Los servicios permitirán usar
todos los recursos técnicos y el sistema distribuido resulto ante no será nada
más, ni nada menos, que un conjunto de servicios que interoperan entre ellos
colaborando para cumplir los objetivos que se han establecido para el sistema.
Los sistemas distribuidos que se diseñen
y construyan deben estar alineados con los objetivos de negocio de la empresa,
aumentar la eficacia y eficiencia operacional de la compañía y permitir el
mayor rendimiento con el menor coste en las estructuras informáticas que dan
soporte.
No olvide nunca estos tres
puntos. El objetivo es siempre alinear tecnología y negocio.
El sistema resultante debe ser
adaptable, ofrecer el rendimiento necesario con el coste más barato que seamos
capaces de conseguir.Con este objetivo final, empezamos nuestro viaje para el
cual le voy a pedir un esfuerzo. Las tecnologías llegan, se consolidan o
desaparecen, y al final mueren. Y siempre con facilidad y rapidez.
Pero las estrategias, las
tácticas y las técnicas de diseño tienen un ciclo de vida mucho más lento y
robusto. Y están por encima de las tecnologías en que se implementan. Intente
poner en su mochila solo las primeras. Este es un viaje por el mundo del diseño
de sistemas distribuidos, no sus técnicas de implementación aunque haremos las
necesarias salidas a ese mundo cunado sea necesario.
Arquitecturas en un sistema
distribuido. La arquitectura de Empresa. La palabra arquitectura es de aquellos
términos utilizados ampliamente dentro del mundo informático. Cuando atacamos
sistemas distribuidos, la palabra aparece continuamente.
Esta constatación de la realidad
no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término:
“Arquitectura es la organización fundamental de un sistema, donde se integran
sus componentes, se establecen las relaciones e interdependencias entre esos
componentes y su entorno y se establecen los principios para su diseño, gestión
y evolución”.
Así, en el mundo de los sistemas
distribuidos donde conviven tantos factores y tan diferentes, es lógico que el
término se utilice profusamente en varios lugares. Veamos la primera aparición.
El objetivo fundamental de cualquier sistema distribuido será aportar valor
añadido. Y para empezar eficientemente el camino conviene organizar de alguna
forma todos los factores que intervienen. La forma de hacerlo es proponer una
Arquitectura deEmpresa, conocida también por EA desde su nombre en inglés,
Enterprise Architecture.
La arquitectura de la empresa
permite a la compañía conocer como es su estructura y la forma en que trabaja.
Es el plano de ruta para el desarrollo de los negocios y de la tecnología que
va ha apoyarlos, tanto en lo nuevo como en la evolución.
Es en este último aspecto por el
que nos conviene acercarnos a ella. Sus contenidos son prerrequisitos que los
sistemas distribuidos deberán cumplir. Es de aquí donde se origina el Plan
Estratégico Distribuido de la Compañía, donde se registrarán todos los
prerrequisitos de desarrollo y gestión que los sistemas distribuidos de la
compañía deberán seguir y cumplir. Veremos que este documento se utilizará en
la segunda parte dedicada al diseño, como base de muchas decisiones a tomar
durante el desarrollo del sistema distribuido.
3.7
Diseño Software 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 diseño del software esta conducido
frecuentemente, tanto por la arquitectura del hardware como por la del
software, por las características del sistema operativo, por los requisitos de
la aplicación y tanto por los extras del lenguaje de programación como
prospectos de diseño.
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 últimas generaciones de coches y programar a nuestros
aparatos.
Todas estas interacciones con las
computadoras sean útiles o intrusivas son ejemplos de computación 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 interacción.