1

Instituto Tecnolgico Superior de Martnez de la

Torre

Ingeniera en Sistemas Computacionales.
Nombre de la asignatura: Ingeniera de Software.
Unidad III: Arquitecturas de software.

Docente: MA. Armando Hernndez Basilio.

Semestre y grupo: 6A.

Alumno:
Cesreo Mah Rubn
Sandoval Monzn Miguel Armando
Snchez Prez Emmanuel Julin
Rodrguez Zamudio Erick

Actividad: Resumen Unidad III.


Lugar y fecha: Martnez de la Torre, Ver. El 21 Mayo del 2014.


2

Unidad III: Arquitecturas de software.
Introduccin ..................................................................................................................... 3
3.1 DESCOMPOSICIN MODULAR ................................................................................. 4
Adaptabilidad: .................................................................................................................. 5
Estilos de descomposicin modular .............................................................................. 5
3.2 PATRONES DE DISEO ........................................................................................ 7
3.3 ARQUITECTURA DE DISEO ESPECFICO ............................................................. 8
3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESO ........................... 9
3.5 DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR ................... 10
3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA. .............................. 11
Arquitectura de objetos distribuidos............................................................................ 11
Middleware ..................................................................................................................... 12
Estndar CORBA ........................................................................................................... 12
3.7 Diseo de software de Arquitectura de Sistema de tiempo real ...................... 14
Sistema de tiempo real como sistema de estimulo ..................................................... 14
Sistemas operativos en tiempo real (RTOS) ................................................................ 14
Componentes del RTOS ................................................................................................ 14
3.8 Conclusin: ......................................................................................................... 16
3.9 Referencias bibliogrficas: ................................................................................. 17












3

Introduccin
En los inicios de la informtica, la programacin se consideraba un arte y se
desarrollaba como tal, debido a la dificultad que entraaba para la mayora de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y
guas 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 construccin, estas indican la estructura, funcionamiento e
interaccin entre las partes del software.
Los buenos des arrolladores de software han adoptado, a menudo, uno o varios
patrones arquitectnicos como estrategias de organizacin del sistema, pero
utilizaban estos patrones de modo informal y no tenan ningn inters en hacerlos
explcitos en el sistema resultante.
En la presente investigacin se definen los diferentes conceptos, caractersticas y
tipos de arquitectura de software, provenientes de diferentes autores y pginas de
Internet del diseo de software as como la descomposicin modular y arquitectura
de dominio especfico.











4

Unidad 3 Arquitecturas de software.
3.1 DESCOMPOSICIN MODULAR
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces.
Ventajas del diseo modular son:
Claridad
Reduccin de costos
Reutilizacin
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se
pueda considerar valida.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
Independencia funcional: Cada mdulo debe realizar una funcin concreta o un
conjunto de funciones afines.
Acoplamiento: El acoplamiento es una medida de la interconexin entre mdulos
en la estructura del programa.
Se tiende a que el acoplamiento sea lo menor posible, esto es, a reducir las
interconexiones entre los distintos mdulos de nuestra aplicacin.
Grados de acoplamiento
Fuerte:
Por contenido, cuando desde un mdulo se puede cambiar datos locales de
otro.


5

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.
Dbil:
De datos, viene dado por los datos que intercambian los mdulos. Es el
mejor.
Sin acoplamiento directo, es el acoplamiento que no existe
Cohesin: Un mdulo coherente ejecuta una tarea sencilla en un procedimiento y
requiere poca interaccin con procedimientos que se ejecutan en otras partes de un
programa.
Comprensibilidad: Para facilitar los cambios, el mantenimiento y la reutilizacin de
mdulos es necesario que cada uno sea comprensible de forma aislada.

Adaptabilidad:
Previsin: es necesario prever que aspectos del sistema pueden ser
susceptibles de cambios en el futuro, y poner estos elementos en mdulos
independientes, de manera que su modificacin afecte al menor nmero de
mdulos posibles
Accesibilidad: debe resultar sencillo el acceso a los documentos de
especificacin, diseo, e implementacin
Consistencia: despus de cualquier adaptacin se debe mantener la
consistencia del sistema, incluidos los documentos afectados

Estilos de descomposicin modular
Hay dos estrategias principales que se pueden usar cuando se descomponga un
subsistema en mdulos:
Descomposicin orientada a objetos: En la que se descompone un
sistema en un conjunto de objetos que se comunican.



6

Descomposicin orientada a flujos de funciones: En la que se
descompone un sistema en mdulos funcionales que aceptan datos y los
transforman en datos de salida.


Fig. 01: descomposicin modular.

Ejemplo:
Sistema de procesamiento de facturas: Una organizacin ha emitido facturas a
sus clientes. Una vez por semana, los pagos realizados se comparan con las
facturas. Para esas facturas pagadas se emite un recibo. Para las facturas que no
has sido pagada dentro del plazo de pago se emite una reclamacin.

Fig. 02: Ejemplo descomposicin modular en una organizacin.


7


Fig. 03: Ejemplo descomposicin modular en una organizacin con
facturacin y recibos.

3.2 PATRONES DE DISEO

Un patrn de diseo se caracteriza como una regla de tres partes que expresa una
relacin entre cierto contexto, un problema y una solucin. Para el diseo de
software, el contexto permite al lector entender el ambiente en el que reside el
problema y qu solucin sera apropiada en dicho ambiente.
Coplien caracteriza un patrn de diseo eficaz del modo siguiente:
Resuelve un problema: los patrones entraan soluciones, no slo principios
o estrategias abstractas.
Es un concepto probado: los patrones incluyen soluciones con un historial,
no teoras o especulaciones
La solucin no es obvia: Los mejores patrones generan indirectamente una
solucin a un problema, enfoque necesario para los problemas ms difciles
del diseo
Describe una relacin: los patrones no slo describen mdulos, sino
estructuras y mecanismos ms profundos del sistema.
El patrn tiene un componente humano significativo: Todo el software
sirve para el confort humano o la calidad de vida; los mejores patrones
recurren explcitamente a la esttica y a la utilidad.


8

Dicho en forma ms clara, un buen patrn de diseo incorpora el conocimiento de
diseo pragmtico, ganado con dificultad, en una forma que permite que otros lo
reutilicen un milln de veces sin elaborarla dos veces de la misma forma.
Existen tres tipos de patrones de relevancia especial para el diseo orientado a
objetos:
Los patrones creacionales: se centran en la creacin, composicin y
representacin de objetos.
Los patrones estructurales: se centran en problemas y soluciones
asociados con la manera en la que se organizan e integran las clases y
objetos para construir una estructura ms grande.
Los patrones conductuales: se enfocan a problemas asociados con la
asignacin de responsabilidad entre los objetos y a la manera en la que se
efecta la comunicacin entre ellos.
3.3 ARQUITECTURA DE DISEO ESPECFICO

Al igual que los modelos gerenciales tambin pueden usarse los modelos
arquitectnicos que son especficos para un dominio particular de aplicacin. Si bien
las instancias de estos sistemas difieren en los detalles, la estructura arquitectnica
comn puede realizarse cuando se desarrollan nuevos sistemas.
Estos modelos arquitectnicos se denominan arquitecturas de dominio especfico,
existen dos tipos:
Modelos genricos: Son abstracciones obtenidas a partir de varios
sistemas reales. Encapsulan las caractersticas principales de estos
sistemas.
Modelos de referencia: son ms abstractos y describen una clase ms
amplia de sistemas. Constituyen un modo de informar los diseadores sobre
la estructura general de esta clase de sistemas. Los modelos de referencia
normalmente se obtienen a partir de un estudio del dominio de la aplicacin.
Representan una arquitectura ideal que incluye todas las caractersticas que
los sistemas podran incorporar.


9

Los modelos genricos tambin pueden servir como modelos de referencia y se
usan normalmente para comunicar conceptos del dominio y comprara o evaluar
posibles arquitecturas.
Las arquitecturas de referencia normalmente no se consideran como un camino
para la implementacin. Su principal funciones una forma de tratar arquitecturas
especficas del dominio. Un modelo de referencia proporciona un vocabulario para
realizar comparaciones. Dicho modelo acta como una base, frente a la cual los
sistemas pueden ser evaluados.

3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESO

Es un sistema en el cual el sistema de software est formado por varios procesos
que pueden (aunque no necesariamente) ejecutarse sobre procesadores diferentes.
Es el modelo ms simple de un sistema distribuido.
Comn en sistemas gran desde tiempo real (estos sistemas recogen
informacin, toman decisiones usando esta informacin y envan seales a
los actuadores que modifican el entorno del sistema).
No son necesariamente sistemas distribuidos (si se disponen ms de un
procesador, entonces se puede implementar la distribucin).

Fig. 04: Ejemplo de arquitectura multiprocesos de un control de trfico.


10

3.5 DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR

Es una aplicacin que se modela como un conjunto de servicios proporcionados por
los servidores y un conjunto de clientes que usan estos servicios (orfaliy harkey,
1998).
Los principales componentes de este modelo son:

1. Un conjunto de servidores que ofrecen servicios a otros subsistemas.
2. Un conjunto de clientes que llaman a los servicios ofrecidos por los
servidores.
3. Una red que permite a los clientes acceder a estos servicios. (No es
estrictamente necesario ya que los clientes y los servidores podra
ejecutarse sobre una nica maquina).

Fig. 05: Estructura de arquitectura cliente-servidor.

Fig. 06: Ejemplo de un sistema bancario arquitectura C/S.


11

3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA.

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.
Ventajas:
Comparticin de recursos.
Apertura
Concurrencia
Escalabilidad
Tolerancia a defectos.
Desventajas
Complejidad
Seguridad
Manejabilidad
Impredecibilidad

Arquitectura de objetos distribuidos

En esta arquitectura los componentes fundamentales del sistema son objetos que
proporcionan una interfaz a un conjunto de servicios que ellos suministran.
Otros objetos realizan llamadas a estos servicios sin hacer ninguna distincin lgica
entre un cliente y un servidor. Varias computadoras en una red y comunicarse a
travs de middleware.



12


Fig. 07 y 08: Estructura de arquitecturas de sistemas distribuidos.
Middleware
Se requiere middleware a dos niveles para soportar la computacin de objetos
distribuidos:
A nivel de comunicacin lgica, el middleware proporciona funcionalidades
que permiten a los objetos intercambiar datos y controlar informacin sobre
diferentes computadoras.
A nivel de componentes, proporciona una base para desarrollar
componentes compatibles. Estndares tales como CORBA, EJB o Active X
proporcionan una base para la implementacin de componentes con
mtodos estndar.
Estndar CORBA

Los estndares CORBA fueron definidos por el Object Management Group (OMG),
que define los estndares para el desarrollo orientado a objeto. Esta propone que
una aplicacin distribuida debera estar formada por varios componentes.
1. Objetos de aplicacin.
2. Objetos estndar definidos para un dominio especfico.
3. Servicios de computacin distribuida.
4. Facilidades horizontales tales como interfaz de usuario



13

Elementos principales de CORBA
Modelo de objetos para objetos de aplicacin: Considera que un objeto es una
encapsulacin de atributos y servicios, como ocurre en los objetos normales. Si un
objeto desea usar los servicios de otro, lo hace a travs de la interfaz (IDL)
Intermediario de peticiones de objetos (ORB): Conoce a los objetos que estn
solicitando servicios y a sus interfaces para as gestionar la comunicacin entre
ellos.
Conjunto de servicios de objetos que son servicios generales.

Fig. 09: Estructura CORBA.
Ventajas del modelo de objetos distribuidos:

Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier
nodo de la red.
Es una arquitectura de sistema abierta que permite aadir nuevos recursos
si es necesario.
El sistema es flexible y escalable. Se pueden crear diferentes instancias del
sistema proporcionndolos mismos servicios por objetos diferentes o por
objetos reproducidos.
Es posible re configurar el sistema de forma dinmica mediante la migracin
de objetos a travs de la red.


14

3.7 Diseo de software de Arquitectura de Sistema de tiempo real

Un sistema de tiempo reales un sistema de software cuyo correcto funcionamiento
depende de los resultados producidos por el mismo y del instante de tiempo en el
que se producen estos resultados.
Sistema de tiempo real como sistema de estimulo
Una forma de ver un sistema de tiempo reales como un sistema de
estmulo/respuesta. Dado un determinado estmulo de entrada, el sistema debe
producirla correspondiente salida.

Fig. 10: Estructura de un sistema de tiempo real.
Los sistemas de tiempo real pueden ser:
Estmulos peridicos: Ocurren a intervalos de tiempo predecibles.
Estmulos a peridicos: Ocurren de forma irregular. Normalmente son
provocados utilizando el mecanismo de interrupciones de la computadora.
Sistemas operativos en tiempo real (RTOS)
Un RTOS gestiona los procesos y asignacin de recursos en un sistema de tiempo
real. Lanza y de tiene los procesos para que los estmulos puedan ser manejados y
asigna memoria y recursos del procesador.
Componentes del RTOS
Los componentes de un RTOS de penden del tamao y la complejidad del sistema
que se est desarrollando. Normalmente, exceptuando los sistemas ms sencillos,
todos incluyen:


15

1. Un reloj de tiempo real: Proporciona informacin para planificar los
procesos de forma peridica.
2. Un manejador de interrupciones: Gestin a las solicitudes a peridicas
de los servicios.
3. Planificador: Se encarga de examinarlos procesos que pueden ser
ejecutados y elegir uno de ellos para su ejecucin.
4. Gestor de recursos: Dado un proceso que es planificado para ejecucin,
el gestor de recursos asigna la memoria adecuada y los recursos del
procesador.
5. Despachador: Tiene la funcin de iniciar la ejecucin de un programa.

Niveles de prioridad
Nivel de Interrupcin: Es el nivel de prioridad ms alto. Se asigna a proceso
que necesitan una respuesta muy rpida. Uno de estos procesos ser el
proceso del reloj de tiempo real.
Nivel de Reloj: Este nivel de prioridad se asigna a los procesos peridicos










16

3.8 Conclusin:

Dentro las arquitecturas de SW existentes que hemos definido anteriormente
existen diferencias importantes que debemos tomar en cuenta antes de llevar a
cabo la construccin de un programa, en la materia de Ingeniera de software
generalmente en la fase de diseo, se analizan estos puntos de acuerdo a los
requisitos y la lgica de metodologas para que este cumpla sus funcionalidades de
manera ptima, tomando en cuenta que algunas arquitecturas de software pueden
ser utilizadas como remplazo de otras, se debe definir con anterioridad la viabilidad
en la utilizacin de esa arquitectura.
La arquitectura del software depende directa y proporcionalmente a los requisitos
del mismo.












17

3.9 Referencias bibliogrficas:

Ian Sommerville (2005).Ingeniera de Software. 7ma Ed,Cap12,pp.12241-258.
Agustn,R.(2013).Arquitectura de software.
Recuperadode:http://ithroshuejutla.blogspot.mx/
Vite,L.(2013).Unidad3:Arquitectura de software.
Recuperadode:http://ithuejutlalvf.blogspot.mx/2013/05/unidad-3-
arquitecturas-de-software.html