Instituto Tecnolgico de Quertaro

Unidad Pinal de Amoles

Divisin de Educacin Presencial a Distancia

Materia: Ingeniera de Software

Ingeniera en Sistemas Computacionales.

Actividad:Tarea 4.Anlisis. Arquitecturas de Software

Alumno:
Jos Luis Prez Ortega

Asesor: L.I. Juan Jose Garca Alcacio

jjgarcia_depad_qro@hotmail.com

Tutor: L.I. Eucebio Martnez Olvera

emartinez_depad_pin@hotmail.com

Domingo 01-Noviembre-2015

Ingeniera de Software 2
Unidad Pinal de Amoles

Anlisis Arquitecturas de Software

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, consiste en un conjunto
de patrones y abstracciones coherentes que proporcionan el marco
Una 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 la mantenibilidad, auditabilidad, flexibilidad e interaccin
con otros sistemas de informacin. Las restricciones son aquellas limitaciones derivadas de las
tecnologas disponibles para implementar sistemas de informacin. Unas 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.

3.1 DESCOMPOSICIN MODULAR

Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los
componentes de diseo (reusables) existentes en un sistema nuevo, producir 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).
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

Jos Luis Prez Ortega

Pgina 2

Ingeniera de Software 3
Unidad Pinal de Amoles
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

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

Jos Luis Prez Ortega

Pgina 3

Ingeniera de Software 4
Unidad Pinal de Amoles
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".

3.3 ARQUITECTURA DE MODELO ESPECFICO

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

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.

Jos Luis Prez Ortega

Pgina 4

Ingeniera de Software 5
Unidad Pinal de Amoles
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.

3.5 DISEO DE SOFTWARE DE CLIENTE SERVIDOR

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.
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 est utilizando en una red mixta.
Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el
procesamiento se distribuye a lo largo de varios procesadores.

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

Jos Luis Prez Ortega

Pgina 5

Ingeniera de Software 6
Unidad Pinal de Amoles
implementacin, Workflows, Servicios Web e Interfaces Grficas declarativas. En la siguiente
grafica se muestran las capas que la conforman.
Un sistema distribuido se define como una coleccin de computadores autnomos conectados por
una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios
como una nica entidad capaz de proporcionar facilidades de computacin.
Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas
estaciones de trabajo conectadas por una red de rea local, hasta Internet, una coleccin de redes
de rea local y de rea extensa interconectados, que en lazan millones de ordenadores.
Las aplicaciones de los sistemas distribuidos varan desde la provisin de capacidad de cmputo a
grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan
prcticamente todas las aplicaciones comerciales y tcnicas de los ordenadores. Los requisitos de
dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y
privacidad de la informacin que el sistema mantiene.
Un sistema distribuido es un sistema de informacin en el cual las funciones se reparten por reas
de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la
organizacin asigna a ese sistema de informacin.
La gestin del sistema debe permitir la coexistencia de varios centros de gestin diferentes. Parte
fundamental del sistema de gestin es el cuadro de mandos. Hay dos cuadros de mandos
diferentes: El cuadro de mandos de seguimiento de los objetivos de negocio pensado para
proporcionar informacin automtica a los gestores de como la realidad se mueve respecto a las
previsiones de los objetivos de negocio en tiempo real. El cuadro de mandos de explotacin
desde donde se centraliza y coordina toda la administracin, supervisin y explotacin del sistema.
Caractersticas

Comparticin de Recursos

Apertura (opennesss)

Concurrencia

Escalabilidad

Tolerancia a Fallos

Transparencia

3.7 Diseo de software de arquitectura de tiempo real arquitectura

El software de tiempo real est 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

Jos Luis Prez Ortega

Pgina 6

Ingeniera de Software 7
Unidad Pinal de Amoles
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.
Cada diseo de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento
de sistema. En la mayora de los casos, el rendimiento de un sistema de tiempo real se mide con
una o ms caractersticas relativas al tiempo, pero tambin se utilizan otras medidas, tales como la
tolerancia al fallo. Algunos sistemas de tiempo real se han diseado para aplicaciones en las que
solo el tiempo de repuesta o la trasferencia de datos es crtica.
Las computadoras se utilizan para controlar una amplia variedad de sistemas desde maquinas
domesticas sencillas hasta plantas enteras de fabricacin. Estas computadoras interactan
directamente con dispositivos hardware. El software de dichos sistemas es software de tiempo
real embebido que debe reaccionar a eventos generados por el hardware y emitir seales de
control como respuesta a estos eventos. Est embebido en sistemas hardware maquina y debe
responder, en tiempo real, a eventos del entorno del sistema.
Los sistemas de tiempo real embebidos son diferentes de otros tipos de sistemas de software. Su
correcto funcionamiento depende de que el sistema responda a los eventos dentro de un corto
intervalo de tiempo. Se puede definir un sistema de tiempo real como sigue:
Un sistema de tiempo real es un sistema software cuyo correcto funcionamiento depende de los
resultados producidos por el mismo y del instante del tiempo en el que se producen estos
resultados. Un sistema de tiempo real blando (soft) es un sistema cuyo funcionamiento se degrada
si los resultados no se producen de acuerdo con los requerimientos temporales especificados. Un
sistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es incorrecto si los
resultados no se producen de acuerdo con la especificacin temporal.
Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero en
algunos casos, no necesita una respuesta rpida. Por ejemplo, el sistema de bombeo de insulina es
un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos
peridicos no es necesario responder muy rpidamente a los eventos externos.
Una forma de ver un sistema de tiempo real es como un sistema de estimulo/respuesta. Dando un
determinado estimulo de entrada, el sistema debe producir la correspondiente salida. Se puede,
por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo una lista de los
estmulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas
deben producirse.

Jos Luis Prez Ortega

Pgina 7