ARQUITECTURAS

DE SOFTWARE

III UNIDAD
VIRIDIANA HERNNDEZ CARBAJAL
ING. EN SISTEMAS COMPUTACIONALES
INGENIERA DE SOFTWARE 6O

DEFINICIN
<< La arquitectura de software de un sistema
de programa o computacin es la estructura de
las estructuras del sistema, la cual comprende
los componentes del software, las propiedades
de esos componentes visibles externamente, y
las relaciones entre ellos. >>
# BAS98

La arquitectura no es el software operacional.

Ms bien, es la representacin que capacita al
ingeniero del software para:

Analizar la efectividad del diseo para la

consecucin de los requisitos fijados.

Considerar las alternativas arquitectnicas en

una etapa en la cual hacer cambios en el
diseo es relativamente fcil.

Reducir los riesgos asociados a la construccin

del software.

IMPORTANCIA
Bass y sus colegas [BAS98].
Las

representaciones de la arquitectura de software facilitan la

comunicacin entre todas las partes (partcipes) interesadas
en el desarrollo de un sistema basado en computadora.

La

arquitectura destaca decisiones tempranas de diseo que

tendrn un profundo impacto en todo el trabajo de ingeniera
del software que sigue, y es tan importante en el xito final
del sistema como una entidad operacional.

La

arquitectura constituye un modelo relativamente pequeo

e intelectualmente comprensible de cmo est estructurado el
sistema y de cmo trabajan juntos sus componentes.

3.1 DESCOMPOSICIN MODULAR

El diseo modular propone dividir el sistema en partes
diferenciadas ms simples y definir sus interfaces.
Sus ventajas:
Claridad.
Reduccin de costos.
Reutilizacin.
Los pasos a seguir son:
Identificar los mdulos.
Describir cada mdulo.
Describir las relaciones entre mdulos.

Cualidades.
Una descomposicin modular debe poseer ciertas
cualidades mnimas para que se pueda
considerar suficiente validad.
Independencia

funcional.

Acoplamiento.
Cohesin.
Comprensibilidad.
Adaptabilidad.

 Independencia funcional.
Al principio cada funcin ser realizada en un
mdulo distinto. Si la funciones son
independientes de los mdulos tendrn
independencia funcional.
Cada mdulo debe realizar una funcin
concreta o un conjunto de funciones afines.
Es recomendable reducir las relaciones entre
mdulos al mnimo.
Para medir la independencia funcional hay dos
criterios: acoplamiento y cohesin

 Acoplamiento
El grado de acoplamiento mide la interrelacin
entre dos mdulos, segn el tipo de
conexin y de la complejidad de la interface.
FUERTE

Por contenido, cuando desde un mdulo

se pueden cambiar datos locales de otro.
Comn, se emplea una zona comn de
datos a la que tienen acceso varios
mdulos.

 MODERADO

De control, la zona comn es un

dispositivo externo al que estn ligados los
mdulos, esto implica que un cambio en el
formato de datos afecta a todos estos
mdulos.
Por etiqueta, en intercambio de datos se
realiza mediante una referencia a la
estructura completa de datos (vector, pila,
rbol, grafo, ).
DBIL

|
De datos, viene dado por los datos que
intercambian los mdulos. Es el mejor
posible.

 Cohesin.
Es necesario lograr que el contenido de cada
mdulo tenga la mxima coherencia. Para
que el n de mdulos no sea demasiado
elevado y complique el diseo se tratan de
agrupar elementos afines y relacionados en
un mismo mdulo.

 Comprensibilidad.
Para facilitar los cambios, el mantenimiento y la
reutilizacin de mdulos es necesario que cada
uno sea comprensible de forma aislada. Para
ello es bueno que posea independencia
funcional, pero adems es deseable:
Identificacin,

el nombre debe ser adecuado y

descriptivo.
Documentacin,

debe aclarar todos los

detalles de diseo e implementacin que no
queden de manifiesto en el propio cdigo.

Simplicidad,

las soluciones
siempre las mejores

sencillas

son

 Adaptabilidad.
La adaptacin de un sistema resulta ms difcil
cuando no hay independencia funcional, es decir,
con alto acoplamiento y baja cohesin, y cuando
el diseo es poco comprensible. Otros factores
para facilitar la adaptabilidad:
Previsin,

es necesario prever que aspectos del

sistema pueden ser susceptibles de cambios en el
futuro.

Accesibilidad,

debe resultar sencillo el acceso a

los documentos.

Consistencia,

despus de cualquier adaptacin

se debe mantener la consistencia del sistema,

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.
<< Cada patrn describe un problema que
ocurre infinidad de veces en nuestro entorno,
as como la solucin al mismo, de tal modo que
podemos utilizar esta solucin un milln de
veces ms adelante sin tener que volver a
pensarla otra vez. >>
# Christopher Alexander, 1979.

 Caractersticas y
objetivos.
Caractersticas:
Efectividad.
Reutilizable.
Objetivos:
Proporcionar catlogos de elementos reusables.
Evitar la reiteracin en la bsqueda de soluciones
a problemas ya conocidos y solucionados
anteriormente.
Estandarizar el modo en que se realiza el diseo.
Facilitar
el
aprendizaje
de
las
nuevas
generaciones de diseadores condensando
conocimiento ya existente.

 Categoras.
Segn la escala o nivel de abstraccin:
Patrones

de arquitectura: Aquellos que

expresan un esquema organizativo estructural
fundamental para sistemas de software.
Patrones de diseo: Aquellos que expresan
esquemas para definir estructuras de diseo (o sus
relaciones) con las qu construir sistemas de
software.
Dialectos: Patrones de bajo nivel especficos para
un lenguaje de programacin o entorno concreto.
Interaccin: Son patrones que nos permiten el
diseo de interfaces web.

 Estructuras o plantillas de
patrones.
Para describir un patrn se usan plantillas ms o
menos estandarizadas
La plantilla ms comn es la utilizada precisamente
por el GoF y consta de los siguientes apartados:
Nombre

del patrn: nombre estndar del

patrn por el cual ser reconocido en la
comunidad (normalmente se expresan en ingls).
Clasificacin del patrn: creacional, estructural
o de comportamiento.
Intencin: Qu problema pretende resolver el
patrn?

 Tambin

conocido como: Otros nombres de

uso comn para el patrn.
Motivacin: Escenario de ejemplo para la
aplicacin del patrn.
Aplicabilidad: Usos comunes y criterios de
aplicabilidad del patrn.
Estructura: Diagramas de clases oportunos
para describir las clases que intervienen en el
patrn.
Participantes: Enumeracin y descripcin de
las entidades abstractas (y sus roles) que
participan en el patrn.
Colaboraciones:
Explicacin
de
las
interrelaciones
que
se
dan
entre
los
participantes.

 Consecuencias:

Consecuencias
positivas
y
negativas en el diseo derivadas de la aplicacin
del patrn.
Implementacin:
Tcnicas
o
comentarios
oportunos de cara a la implementacin del patrn.
Cdigo de ejemplo: Cdigo fuente ejemplo de
implementacin del patrn.
Usos conocidos: Ejemplos de sistemas reales
que usan el patrn.
Patrones relacionados: Referencias cruzadas
con otros patrones.

3.3 ARQUITECTURA DE
DOMINIO ESPECFICO.
Son abstracciones sobre un dominio de
aplicacin.
Se trata de estructuras arquitectnicas comunes
que se reutilizan cuando se desarrollan nuevos
sistemas que difieren en detalles de los
anteriormente implementados.
Existen dos modelos de dominio especfico:
Modelos

genricos.
Modelos de referencia.

 Modelos genricos.
Son

abstracciones de varios sistemas reales que

encapsulan las caractersticas principales de
estos sistemas.

Se

pueden utilizar directamente en el diseo.

Se

derivan de forma ascendente a partir de los

sistemas existentes.

Pocos

modelos genricos estn disponibles al

pblico; las organizaciones que desarrollan estos
modelos los ven como una propiedad intelectual
necesaria para el desarrollo de futuros sistemas.

 Modelos de referencia.
Son

modelos abstractos idealizados del dominio

que describen a una clase mayor de sistemas.

No

necesariamente reflejan la arquitectura real

de sistemas existentes en el dominio.

Se

utilizan para comunicar conceptos del

dominio y comparar las posibles arquitecturas.

Se

derivan de forma descendente.

Algunos

patrones de diseo se consideran como

arquitecturas de referencia.

Tipos de arquitecturas.
Existen 4 tipos de arquitecturas de dominio
especfico:
Arquitectura

multiprocesador.
Arquitectura cliente/servidor.
Arquitectura distribuida.
Arquitectura de tiempo real.

3.4 DISEO DE SOFTWARE DE LA

ARQUITECTURA
MULTIPROCESADOR
Este sistema consiste de varios procesos que
pueden ejecutarse sobre procesadores
diferentes (aunque no es necesario), es muy
comn en sistemas grandes de tiempo real,
recolectan informacin, toman decisiones,
con la afirmacin, y envan seales a los
actuadores que modifican el entorno del
sistema.
El uso de mltiples procesadores mejora el
rendimiento y adaptabilidad del sistema.

Un ejemplo es un modelo simplificado de un sistema de

control de trfico. Un conjunto de sensores distribuidos
recogen informacin sobre le flujo de trfico y la procesan
localmente antes de enviarla a una sala de control. Los
operadores toman decisiones usando esta informacin y
dan instrucciones a un proceso de control de diversas
luces de trfico.

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 se
recursos.
Pase

de mensaje:
MPI ("Message Passing Interface") es un estndar
que define la sintaxis y la semntica de las
funciones usada en programas que exploten la
existencia de mltiples procesadores.

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

El

uso de componentes comnmente disponibles,

en grandes cantidades, permite ofrecer mayor
rendimiento.

Desventajas:
Puede

ser limitante fsica, existen factores que

limitan la velocidad mxima de un procesador
independiente del factor econmico.

Las

barreras fsicas infranqueables tales como la

velocidad de la luz, efectos al reducir el tamao.

Problemas

causados por fenmenos elctricos a

pequeas escalas restringen la capacidad
mxima del sistema multiprocesador.

3.5 DISEO DE SOFTWARE DE LA

ARQUITECTURA CLIENTE-SERVIDOR
El modelo arquitectnico cliente-servidor es un
modelo de sistema en el que dicho sistema
organiza como un conjunto de servicios y
servidores asociados, ms unos clientes que
acceden y usan los servicios.

Principales componentes:
El

cliente:
El cliente es el proceso que permite al usuario
formular los requerimientos y pasarlos al
servidor, se le conoce con el trmino front-end.
Funciones que lleva a cabo el proceso cliente:
Administrar la interfaz de usuario.
Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones
locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.

 El

servidor:

Es el proceso encargado de atender a mltiples clientes

que hacen peticiones de algn recurso administrado por
l. Al proceso servidor se le conoce con el trmino backend.
Funciones que lleva a cabo el proceso servidor:
Aceptar los requerimientos de bases de datos que hacen los
clientes.
Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los clientes.
Procesar la lgica de la aplicacin y realizar validaciones a
nivel de bases de datos.
Ejemplos:

Servidores de ficheros
Servidores de impresoras
Servidores de compilacin

Caractersticas:
Los

clientes pueden conocer el nombre de los

servidores disponibles y los servicios que stos
proporcionan.

Los

servidores no necesitan conocer la

identidad de los clientes o cuantos clientes
tienen.

Los

clientes acceden a los servicios

proporcionados por un servidor a travs de
llamadas a procedimientos remotos usando un
protocolo http usado en la WWW.

Arquitectura

de un Sistema de biblioteca y fotografa

Ventajas ms
importantes:
Es

una arquitectura distribuida.

Se

puede hacer un uso efectivo de los sistemas

en red con muchos procesadores distribuidos.

Es

fcil aadir un nuevo servidor e integrarlo

con el resto del sistema o actualizar los
servidores de forma transparente sin afectar al
resto del sistema.
Solicitud de Recurso
CLIENTE

SERVICIO
Respuesta
PRG

BD

SERVICIOS

3.6 DISEO DE SOFTWARE

DE
ARQUITECTURA
DISTRIBUIDA

<< 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. >>
# Enric Martnez Gomriz.

Esta definicin no obliga a que los servicios sean

internos ni fabricados por la propia organizacin.

 Elementos.
Objetivos

de la

empresa.
Infraestructura.
Plataforma de
proceso: elemento
encargado de
proporcionar los
recursos fsicos y el
software de base para
ejecutarlo.
Conectividad: Son
bsicamente las redes
y las comunicaciones.

 Elementos.
Datos.
Almacenamiento de
datos: formado por
los datos en si y los
gestores donde se
localizan.
Seguridad.
Sistemas de
seguridad.

 Elementos.
Software.
Aplicaciones.
Servicios.
Interfaces.
Gestin del
sistema: como un
conjunto integrado y
coordinado a travs
de los recursos de
direccin y
administracin.

El objetivo es siempre alinear tecnologa y

negocio.

3.7 DISEO DE SOFTWARE DE

ARQUITECTURA DE TIEMPO REAL
<< Un sistema de tiempo real es un software
cuyo correcto funcionamiento depende de
los resultados producidos por el mismo y
del instante de tiempo en el que se producen
estos resultados. >>
Una forma de ver un sistema en tiempo real es
como un sistema de estimo/respuesta.

 Clases.
Estmulos

peridicos. Ocurren a intervalos de

tiempos predecibles .por ejemplo, el sistema
debe de tener un sensor cada 50mili
segundosy realizar una accin respuesta)
dependiendo del valor de ese sensor (estimulo).

Estmulos

aperidicos. Ocurren de forma

irregular.
Normalmente
son
provocados
utilizando el mecanismo de interrupciones de la
computadora. un ejemplo de dicho estimo
podra ser una interrupcin para indicar que
una trasferencia de E/S sea completado y que
los datos estn disponibles en un buffer.

 Componentes.
Un

reloj de tiempo real: proporciona la

informacin para planificar los procesos en
forma peridica.

Un

manejador de interrupciones: gestiona

las solicitudes aperidicas de los servicios.

Gestor

de recursos: asigna la memoria

adecuada.

Un

despachador: la funcin de iniciar la

ejecucin de un proceso.