Instituto Tecnológico de Querétaro

Unidad Pinal de Amoles

División de Educación Presencial a Distancia

Materia: Ingeniería de Software

Ingeniería en Sistemas Computacionales.

Actividad:Tarea 4.Análisis. Arquitecturas de Software

Alumno: José Luis Pérez Ortega

Asesor: L.I. Juan Jose García Alcacio

jjgarcia_depad_qro@hotmail.com

Tutor: L.I. Eucebio Martínez Olvera

emartinez_depad_pin@hotmail.com

Domingo 01-Noviembre-2015

Ingeniería de Software Unidad Pinal de Amoles

2

J o s é L u i s P é r e z O r t e g a

Página 2

Análisis Arquitecturas de Software 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.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).

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

Ingeniería de Software Unidad Pinal de Amoles

3

J o s é L u i s P é r e z O r t e g a

Página 3

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.

Ingeniería de Software Unidad Pinal de Amoles

4

J o s é L u i s P é r e z O r t e g a

Página 4

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

3.3 ARQUITECTURA DE MODELO ESPECÍFICO 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.

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.

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.

Ingeniería de Software Unidad Pinal de Amoles

5

J o s é L u i s P é r e z O r t e g a

Página 5

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.

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.

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

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

Ingeniería de Software Unidad Pinal de Amoles

6

J o s é L u i s P é r e z O r t e g a

Página 6

implementación, Workflows, Servicios Web e Interfaces Gráficas declarativas. En la siguiente

grafica se muestran las capas que la conforman.

Un sistema distribuido se define como una colección de computadores autónomos 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 computación.

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 colección de redes

de área local y de área extensa interconectados, que en lazan millones de ordenadores.

Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de cómputo a

grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan

prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de

dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y

privacidad de la información que el sistema mantiene.

Un sistema distribuido es un sistema de información en el cual las funciones se reparten por áreas

de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la

organización asigna a ese sistema de información.

La gestión del sistema debe permitir la coexistencia de varios centros de gestión diferentes. Parte

fundamental del sistema de gestión 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 información automática 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 explotación

desde donde se centraliza y coordina toda la administración, supervisión y explotación del sistema.

Características

· Compartición de Recursos

· Apertura (opennesss)

· Concurrencia

· Escalabilidad

· Tolerancia a Fallos

· Transparencia

3.7 Diseño 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

Ingeniería de Software Unidad Pinal de Amoles

7

J o s é L u i s P é r e z O r t e g a

Página 7

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.

Cada diseño de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento

de sistema. En la mayoría de los casos, el rendimiento de un sistema de tiempo real se mide con

una o más características relativas al tiempo, pero también se utilizan otras medidas, tales como la

tolerancia al fallo. Algunos sistemas de tiempo real se han diseñado para aplicaciones en las que

solo el tiempo de repuesta o la trasferencia de datos es crítica.

Las computadoras se utilizan para controlar una amplia variedad de sistemas desde maquinas

domesticas sencillas hasta plantas enteras de fabricación. Estas computadoras interactúan

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 señales 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 especificación temporal.

Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero en

algunos casos, no necesita una respuesta rápida. Por ejemplo, el sistema de bombeo de insulina es

un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos

periódicos no es necesario responder muy rápidamente 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

estímulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas

deben producirse.