DISEO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE

El diseo del software se encuentra en el ncleo tcnico de la ingeniera del

software y se aplica independientemente del modelo de diseo de software que se
utilice. Una vez que se analizan y especifican los requisitos del software.

3.1 DESCOMPOSICION MODULAR

Descomposicin modular.

El principal objetivo de la descomposicin modula es de componer los problemas

difciles en problemas sencillos de tal manera sera mas eficiente el desarrollo
del sistema. La descomposicin modular se enfoca en reutilizar cdigo, adems
debido a esta descomposicin cada mdulo es desarrollado con un fin especfico,
de esta manera los futuros programadores comprendern fcilmente la funcin
de cada mdulo.
Un ejemplo de la descomposicin se puede observar en la figura1.

Figura1. Cabe resaltar los mdulos, que son la muestra de la descomposicin

modular del primer modulo
Las caractersticas de los mdulos son:
Tamao pequeo
Independencia modular
Abstraccin

Encapsulamiento
Mientras que los objetivos de la Descomposicin Modular son:
Descomponer los problemas complejos en problemas ms sencillos
Reutilizar el cdigo
Facilitar la lectura de los programa
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces. Las ventajas seran: la claridad, reduccin de costos y reutilizacin.

3.2 PATRONES DE DISEO

Los patrones de diseo son 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 su efectividad resolviendo problemas
similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que
significa que es aplicable a diferentes problemas de diseo en distintas
circunstancias.

OBJETIVOS DE LOS PATRONES

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.

CATEGORAS DE PATRONES
Segn la escala o nivel de abstraccin:

Patrones de arquitectura: Aquellos que expresan

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.

un

esquema

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.

3.3 ARQUITECTURA DE DOMINIO ESPECFICO

Para el desarrollo de software existen diversas arquitecturas de dominio
especfico. Que seran: Diseo de software de arquitectura multiprocesador,
diseo de software distribuido, diseo de software distribuido en tiempo real y
diseo de software cliente/servidor
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
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 peerto-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.

3.4
DISEO
DE
MULTIPROCESADOR

SOFTWARE

DE

ARQUITECTURA

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios

procesos de forma concurrente, un multiprocesador es aquel que cuenta con dos
o ms microprocesadores.
Un sistema multiproceso o multitarea es aquel que permite que se ejecuten varios
procesos de forma concurrente. Cabe recalcar que a nica forma de que se

ejecuten de forma simultnea varios procesadores es tener varias CPUs (ya

sea en una maquina en o en varias, en un sistema distribuido).
El multiproceso no es ms que un conjunto de tareas que pueden ser
completadas rpidamente si hay varias unidades de proceso ejecutndolas. Para
el desarrollo de estos procesos se ocupan modelos de programacin concurrente
y paralela:
Los objetivos de la programacin paralela, son:
Reducir el tiempo de cmputo.
Reducir la complejidad del algoritmo,
Aprovechar al mximo la capacidad de las computadoras multiproceso.
Existen diferentes tipos de programacin:
Multihilo: El cual permite a una aplicacin realizar varias tareas concurrentemente.
Los distintos hilos que se ejecutan comparten una serie de recursos.

Figura 2. Se puede observar la existencia de mltiples procesadores.

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. Los hilos que se
ejecutan comparten ciertos recursos como el espacio del mensaje, la cual
permite simplificar el diseo de una aplicacin que debe llevar a cabo distintas
funciones simultneamente.

DISEO DE SOFTWARE DE CLIENTE

SERVIDOR
3.5

La arquitectura cliente-servidor es 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 diferentes
computadoras aumentando 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 el remitente 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 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.
Al receptor de la solicitud enviada por el cliente 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 luego 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. Esta centralizacin
tambin facilita la tarea de poner al da datos u otros recursos (mejor que en las
redes P2P)..
Escalabilidad: se puede aumentar la capacidad de clientes y servidores por
separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier
momento, o se pueden aadir nuevos nodos a la red (clientes y/o servidores).

Fcil mantenimiento: al estar distribuidas las funciones y responsabilidades entre

varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o
incluso trasladar un servidor, mientras que sus clientes no se vern afectados por
ese cambio (o se afectarn mnimamente). Esta independencia de los cambios
tambin se conoce como encapsulacin.
Existen tecnologas, suficientemente desarrolladas, diseadas para el paradigma
de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la
interfaz, y la facilidad de empleo.
Desventajas: La congestin del trfico ha sido siempre un problema en el
paradigma de C/S. Cuando una gran cantidad de clientes envan peticiones
simultaneas al mismo servidor, puede ser que cause muchos problemas para ste
(a mayor nmero de clientes, ms problemas para el servidor). Al contrario, en las
redes P2P como cada nodo en la red hace tambin de servidor, cuanto ms nodos
hay, mejor es el ancho de banda que se tiene.
El paradigma de C/S clsico no tiene la robustez de una red P2P. Cuando un
servidor est cado, las peticiones de los clientes no pueden ser satisfechas. En la
mayor parte de redes P2P, los recursos estn generalmente distribuidos en varios
nodos de la red. Aunque algunos salgan o abandonen la descarga; otros pueden
todava acabar de descargar consiguiendo datos del resto de los nodos en la red.
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 coste.
El cliente no dispone de los recursos que puedan existir en el servidor. Por
ejemplo, si la aplicacin es una Web, no podemos escribir en el disco duro del
cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana
previa de impresin de los navegadores.

3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA

INTRODUCCIN

Prcticamente todo los grandes sistemas informticos son en la actualidad

sistemas distribuidos. Un sistema distribuido es un sistema en el que el
procesamiento de informacin se distribuye sobre varias computadoras en vez de
estar confinado en una nica mquina. Obviamente, la ingeniera de sistemas
distribuidos tiene mucho en comn con la ingeniera de cualquier otro software,
pero existen cuestiones especficas que deben tenerse en cuenta cuando se
disea este tipo de sistemas.
Se identifican las siguientes ventajas del uso de una aproximacin distribuida para
el desarrollo de sistemas:
1.Comparticin de recursos. Un sistema distribuido permite compartir recursos
hardware y software como discos, impresoras, ficheros y compiladores que se
asocian con computadoras de una red.
2.Apertura. Los sistemas distribuidos son normalmente sistemas abiertos, lo que
significa que se disean sobre protocolos estndar que permiten combinar
equipamiento y software de diferentes vendedores.
3.Concurrencia. En un sistema distribuido, varios procesos pueden operar al
mismo tiempo sobre diferentes computadoras de la red. Estos procesos pueden
(aunque no necesariamente) comunicarse con otros durante su funcionamiento
normal.
4.Escalabilidad. Al menos en principio, los sistemas distribuidos son escalables en
tanto que la capacidad del sistema puede incrementarse aadiendo nuevos
recursos para cubrir nuevas demandas sobre el sistema. En la prctica, la red que
una las computadoras individuales del sistema puede limitar la escalabilidad del
sistema. Si se aaden muchas computadoras nuevas, entonces la capacidad de la
red puede resultar inadecuada.
5.Tolerancia a defectos. La disponibilidad de varias computadoras y el potencial
para reproducir informacin significa que los sistemas distribuidos pueden ser
tolerantes a algunos fallos de funcionamiento del hardware y del sofware. En la
mayora de los sistemas distribuidos, se puede proporcionar un servicio degradado
cuando ocurren fallos de funcionamiento; una completa prdida de servicio slo
ocurre cuando existe un fallo de funcionamiento en la red.
Para sistemas organizacionales a gran escala, estas ventajas significan que los
sistemas distribuidos han reemplazado ampliamente a los sistemas heredados
centralizados que fueron desarrollados en los aos 80 y 90. Sin embargo,
comparados con sistemas que se ejecutan sobre un nico procesador o un clster
de procesadores, los sistemas distribuidos tienen varias desventajas:

1.Complejidad. Los sistemas distribuidos son ms complejos que los sistemas

centralizados. Esto hace ms difcil comprender sus propiedades emergentes y
probar estos sistemas. Por ejemplo, en vez de que el rendimiento del sistema
dependa de la velocidad de ejecucin de un procesador, depende del ancho de
banda y de la velocidad de los procesadores de la red. Mover los recursos de una
parte del sistema a otra puede afectar de forma radical al rendimiento del sistema.
2.Seguridad. Puede accederse al sistema desde varias computadoras diferentes, y
el trfico en la red puede estar sujeto a escuchas indeseadas. Esto hace ms
difcil el asegurar que la integridad de los datos en el sistema se mantenga y que
los servicios del sistema no se degraden por ataques de denegacin de servicio.
3.Manejabilidad. Las computadoras en un sistema pueden ser de diferentes tipos y
pueden ejecutar versiones diferentes de sistemas operativos. Los defectos en una
mquina pueden propagarse a otras mquinas con consecuencias inesperadas.
Esto significa que se requiere ms esfuerzo para gestionar y mantener el
funcionamiento del sistema.
4.Impredecibilidad. Como todos los usuarios de la WWW saben, los sistemas
distribuidos tienen una respuesta impredecible. La respuesta depende de la carga
total en el sistema, de su organizacin y de la carga de la red. Como todos ellos
pueden cambiar con mucha rapidez, el tiempo requerido para responder a una
peticin de usuario puede variar drsticamente de una peticin a otra.
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 inherentes a estos sistemas. Para hacer eso, se necesita
comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas
distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas
distribuidos:
1.Arquitectura cliente-servidor. En esta aproximacin, el sistema puede ser visto
como un conjunto de servicio 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.
2.Arquitecturas de objetos distribuidos. En este caso, 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, intra organizacional. Aqu tambin se

plantean dos tipos ms de arquitecturas distribuidas que son ms adecuadas para

la distribucin inter organizacional: arquitectura de sistemas peer-to-peer (p2p) y
arquitecturas orientadas a servicios.
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 sita
en medio de los diferentes componentes distribuidos del sistema.
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 pueden 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.

3.7 DISEO DE SOFTWARE DE ARQUITECTURA DE

TIEMPO REAL ARQUITECTURA
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.
Arquitectura Multiprocesador
Un sistema multiproceso o multitarea es aquel que permite ejecutar varios
procesos de forma concurrente, la razon es porque actualmente la mayoria de las
cpus solo pueden ejecutar un proceso cada vez. La unica 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 recide en la operacion 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 dificil de entender : mas procesadores significa mas
potencia computacional.
Un conjunto de tareas puede ser completado mas rapidamente si hay varias
unidades de proceso ejecutandolas en paralelo.