Arquitectura de

Software(POO)
IT&S 2.0
Arquitectura de Software
•Es la organización fundamental de un sistema encarnada en sus
componentes, las relaciones entre ellos y el ambiente y los
principios que orientan su diseño y evolución.

•También denominada Arquitectura lógica, consiste en un

conjunto de patrones y abstracciones coherentes que
proporcionan el marco de referencia necesario para guiar la
construcción del Software.
Patrones de Software

• Propósito
 Compartir una solución probada,
 ampliamente aplicable
 a un problema particular de diseño.
 El patrón se presenta en una forma estándar que
permite que sea fácilmente reutilizado.
• Cinco piezas importantes de un patrón
 Nombre
 Contexto
 Problema
 Solución
 Consecuencias (positivas y negativas)
 Estilos, Patrones e Idioms

• Los patrones de diseño se agrupan en tres tipos

 Estilos arquitectónicos: Soluciones de organización a nivel
del sistema

 Patrones de diseño: Soluciones a problemas

detallados de diseño de software

 Idioms: Soluciones útiles para problemas específicos en algún

lenguaje de programación
 Estilos Arquitectónicos

• Un estilo arquitectónico
 expresa un esquema de organización estructural para
sistemas de software.
 Provee un conjunto de tipos de elementos
predefinidos,
 especifica sus responsabilidades e
 incluye reglas y guías para organizar las relaciones
entre ellos
 Patrones de Diseño

• Un patrón de diseño
 provee un esquema para refinar los elementos de un
sistema de software o las relaciones entre ellos.
 Describe una estructura recurrente de elementos de
diseño interconectados que soluciona un problema
general de diseño dentro de un contexto particular
 Idioms

• Un idiom
 es un patrón de bajo nivel, específico para un
lenguaje de programación.
 Describe como implementar aspectos particulares de
elementos o de las relaciones entre ellos usando las
características de un lenguaje particular.
 ¿Otros aspectos de la arquitectura

Seguridad Confiabilidad Rendimiento Usabilidad

Eficiencia
Facilidad de
Mantenibilidad (memoria,
Prueba
ejecución)

Portabilidad Disponibilidad Reusabilidad Escalabilidad

Modificabilid
ad
Extensibilidad otras
¿De qué forma impacta el uso un estilo en las
propiedades del sistema?
Estilos Arquitectónicos
Estilos de Flujo de Datos
• Tubería y filtros
Estilos Centrados en Datos
• Arquitecturas de Pizarra o
Repositorio
Estilos de Llamada y Retorno
• Model-View-Controller (MVC)
• Arquitecturas en Capas
• Arquitecturas Orientadas a
Objetos
• Arquitecturas Orientada en
Componentes
Estilos de Negocio
• Bussines Process management
Estilos de Código Móvil
• Arquitectura de Máquinas
Virtuales
Estilos heterogéneos
• Sistemas de control de procesos
• Arquitecturas Basadas en
Atributos
Estilos Peer-to-Peer
• Arquitecturas Basadas en Eventos
• Arquitecturas Orientadas a
Servicios
• Arquitecturas Basadas en Recursos
• Arquitectura de Microservicios
Arquitectura tubos y filtros
Se basa en un patrón tuberías y filtros. Este consta de un
conjunto de componentes denominados “filtros”
conectados entre sí por “tuberías” que transmiten los
datos desde un componente al siguiente. Cada filtro
trabaja de manera independiente de los componentes
que se encuentren situados antes o después de ella. Se
diseñan de tal modo que esperan que un conjunto de
datos en un determinado formato. Y obtiene como
resultado datos de salida en un formato especifico.
El sistema es visto como una serie de transformaciones
sobre piezas sucesivas de datos de entrada. El dato
ingresa en el sistema, y fluye entre los componentes, de
uno en uno, hasta que se le asigne un destino final (salida
o repositorio).
La aplicación típica del estilo es un procesamiento clásico
de datos: el cliente hace un requerimiento; el
requerimiento se valida; un Web Service toma el objeto
de la base de datos; se lo convierte a HTML; se efectúa la
representación en pantalla. El estilo tubería-filtros
propiamente dicho enfatiza la transformación
incremental de los datos por sucesivos componentes.
Arquitectura de flujode datos
Si el flujo de datos degenera en una sola línea de
transformaciones se denomina procesamiento por
lotes secuencial. Esta estructura acepta un
procesamiento por lotes de datos y luego aplica una
serie de componentes secuenciales (filtro) para
transformarlos.

Filtro Filtro

Filtro
Filtro Filtro Filtro

Filtro Filtro Filtro

Tuberías
Filtro
 Arquitectura de flujode datos
Ventajas
Permite entender el sistema global en términos de la
combinación de componentes
Soporta de buena manera la reutilización
• Los filtros son independientes de sus vecinos
Facilidad de mantenimiento y mejora
Facilidad de diagnóstico (rendimiento y Dead-lock)
Soportan la ejecución concurrente
Desventajas
No aconsejable para cuando se necesita
interactividad
Problemas de rendimiento ya que los datos se
transmiten en forma completa entre filtros.
Arquitectura centrada en datos
Un almacén de datos se encuentra en el centro de
esta arquitectura.
Otros componentes tienen acceso a él y cuentan
con la opción de actualizar, agregar, eliminar o por
otra parte, modificar los datos de ese almacén.
El SW cliente tiene acceso a un almacén central. En
algunos casos este es pasivo, es decir, el SW cliente
accede a los datos independiente de cualquier
cambio hecho a los datos o a las acciones de otros
SW cliente.
Una variación de este enfoque transforma el depósito
en un “pizarrón” que envía notificaciones al SW
cliente cuando cambian los datos de interés para el
cliente.
Arquitectura centrada en datos
Una arquitectura centrada en datos promueve la
capacidad de integración, esto significa que es
posible cambiar componentes existentes y agregar
nuevos componentes cliente a la arquitectura sin
preocuparse por otros clientes (ya que los
componentes clientes operan en forma
independiente).
Además es posible pasar datos entre clientes
empleando el mecanismo del pizarrón, es decir, el
componente pizarrón sirve para coordinar la
transferencia de información entre clientes.
Los componentes cliente ejecutan los procesos de
manera independiente.
 Arquitectura centrada en datos

Software cliente Software cliente

Software cliente Almacén de datos Software cliente

(depósito o pizarrón)

Software cliente Software cliente

Arquitectura centrada en datos

Aplicación / Aplicación / Aplicación /

Modulo 1 Modulo 2 Modulo 3

Repositorio
(Base de Datos, Sistema de Archivos,
Memoria Compartida, etcétera)

Aplicación / Aplicación /
...
Modulo 4 Modulo N

Repositorio / Pizarron
Arquitectura centrada en datos
Ventajas
Posibilita la integración de agentes.
Adecuado para la resoluc ión de problemas no
deterministas
Se puede resumir el estado de conoc imiento en
cada momento del proceso.
Desventajas
Estructura de datos común a todos los agentes
Problemas de carga a la hora de chequear y vigilar
el estado de la pizarra
Arquitectura Orientada a Objetos
Los componentes de un sistema encapsulan los
datos y las operaciones que deben aplicarse para
manipular los datos. La comunicación y
coordinación entre los componentes se consigue
mediante el paso de mensajes.
Restricciones
Los objetos son responsables de la integridad
de susrepresentaciones
Dicha representación es ocultada al resto de los
objetos
Arquitectura Orientada a Objetos
Ventajas
Gracias al invariante de ocultación es posible
reemplazar la implementación sin que afecte a los
clientes (“clientes” del objeto)
Desventajas
Para invocar métodos de un objeto se debe conocer
su identidad
Parece obvio, pero no lo es en absoluto!
Efectos colaterales
Arquitectura de llamada y retorno
Con esta arquitectura se obtiene una estructura
de programa que resulta relativamente fácil de
modificar y cambiar de tamaño.
Existen dos subestilos:
Arquitectura de programa principal/subprograma:
Esta estructura de programa clásica separa la
función en una jerarquía de control donde un
programa “principal” invoca a varios
componentes de programa, que a su vez pueden
invocar a otros componentes.
Arquitectura de llamada a procedimiento remoto:
Los componentes de una arquitectura de
programa principal/subprograma se distribuyen
entre varias computadoras de una red.
 Arquitectura de llamada y retorno
Programa
Principal

Subprograma Subprograma Subprograma

controlador controlador controlador

Subprograma Subprograma Subprograma Subprograma Subprograma

de aplicación de aplicación de aplicación de aplicación de aplicación

Subprograma Subprograma
de aplicación de aplicación
 Arquitectura en capas

Hay varias capas definidas, cada una de ellas realiza

operaciones que se acercan progresivamente al
conjunto de instrucciones de la máquina.
En la capa externa los componentes sirven a las
operaciones de interfaz del usuario.
En la ca pa interna los componentes sirven como
interfaz con el sistema operativo.
Las capas intermedias proporcionan servic ios de
utilería y de SW de aplicaciones
 Arquitectura en capas

Módulos Capa de la
interfaz de
usuario

Capa de la
Aplicación

Capa de
Utilerías

Capa
Central
 Arquitectura en capas

LAYERS YTIERS

Layer: capa arquitectónica de la aplicación

software
Presentación, lógica, persistencia
Tier: capa física de la arquitectura de despliegue del
hardware
Máquinas: Servidor web, servidor de aplicaciones,
servidor de base de datos
Las “layers” se despliegan sobre las “tiers”
 Arquitectura en capas
Ventajas
Facilita la descomposic ión del problema en varios
niveles de abstracción.
Soporta fá cilmente la evolución del sistema, los
cambios sólo afectan a las capas vecinas
Se pueden cambiar las implementaciones
respetando las interfaces con las capas adyacentes
Desventajas
No todos los sistemas pueden estructurarse en capas
A menudo es difícil encontrar la separación en capas
adecuadas
 Arquitectura en capas

Una arquitectura monolítica describe una

aplicación en la que toda la funcionalidad
del sistema (ej. acceso a datos, interfaz de
usuario, lógica, etcétera) está
implementada y mezclada en una sola
capa.

Esto, en la gran mayoría de los casos, no

es una buena idea... ¿Por qué?
Sistema
(TODO EL
SISTEMA)
 Arquitectura en capas

Petición

Respuesta
Cliente
1

Red Servidor
1
...
Internet,
Cliente LAN, WAN
2
...

Servidor
Cliente N
N

Cliente Servidor
 Arquitectura en capas

Petición

Respuesta

Red

Cliente
Servidor

Liviano: Lógica de la Aplicación solamente del lado del

servidor

Pesado: Lógica de la Aplicación parcial o totalmente del lado

del cliente

Cliente “Liviano” vs Cliente Pesado

Evolución de arquitectura en capas
Arquitectura Cliente Servidor
Arquitectura Cliente Servidor
 Cliente /Servidor

Capa de
Presentación
Capa de
Proceso /
(Interfaz
Negocio
Gráfica de Capa de
Usuario) BD
(Lógica / Persistencia
Reglas de
(HTML, JSP,
Negocio)
AP, PHP,
etcétera)

Arquitectura a tres Capas

 Arquitectura en capas
Cuando usar 3capas

• Muchos servicios.
• Aplicaciones en diferentes lenguajes, o diferentes
proveedores.
• BD heterogéneas.
• Aplicaciones de larga duración (se proveen
cambios).
• Gran cantidad de transacciones al día o muchos
usuarios concurrentes.
• Comunicación entre aplicaciones.
 Beneficios del Modelo C/S
Acceso a la información
Incremento de la productividad
Procesos Automáticos
Potentes capacidades para reportes
Mejoramiento del servicio de usuario
Desarrollo rápido de aplicaciones
Reducción de costos de desarrollo
Apoyo a la toma de decisiones
Rápida respuesta a un mercado cambiante
 Arquitectura N capas

Capa 1 API

Mas Seguridad / Protección

Interfaz
Menos Abstracción

Capa 2

...

Capa N
Arquitectura en capas
Arquitectura en capas
Modelo-View-Controlador
El patrón de arquitectura de modelo-view-controlador
(MVC) divide una aplicación interactiva en tres partes.
El modelo contiene los datos y la funcionalidad
esencial. Las views despliegan la información al
usuario. Los controladores manejan el input. Las views
Modelo juntos•componen
y los controladores
Lógica la interfaz con el
de Negocio
usuario. El mecanismo de cambio-propagación
asegura la consistencia de la interfaz con el modelo.

Vista • Interfaz de usuario

Controlador • Lógica de Control

Modelo-Vista-Control (MVC)

Utilizado para construir interfaces de usuario en Smalltalk-80.

Basado en tres tipos de objetos:
Modelo: objeto aplicación. Encapsula el núcleo funcional y los datos involucrados.
Vistas: presentación de información por pantalla (al usuario).
Controlador: define la forma en la que debe reaccionar la interfaz del usuario,
frente a la entrada de datos (del usuario).

Desacopla el modelo de las vistas.

Hace a los sistemas más mantenibles, flexibles y adaptables.
Ejemplo: Sistema de Información

Negro: 43%
Rojo: 39%
Sistema de elecciones Azul: 6%
políticas. Verde: 10%
Otro: 2%
Los usuarios votan a través
de una interfaz gráfica.
La información se muestra 50

40
Negro 43
con distintos formatos. 30
Rojo 39
20 Azul 6
Los cambios por votación 10 Verde 10
0 Otro 2
deben reflejarse en Negro Rojo Azul Verde Ot ro

forma inmediata.
Debe poderse integrar otras formas de
presentación de los resultados tales como la
distribución de candidatos en el parlamento.
Las presentaciones deben ser portables.
Modelo-Vista-Control (MVC)

Contexto: Aplicaciones interactivas con interfaces humano-

computador cambiantes y flexibles.
Problema:
Las interfaces de usuario son muy frecuentemente cambiadas.
Cambios en la funcionalidad deben reflejarse en las interfaces.
Puede haber interfaces a medida para ciertos usuarios.
Diferentes paradigmas de interfaz:
digitar información,
seleccionar íconos.
Construir un sistema monolítico es caro y difícil.
Modelo-Vista-Control (MVC)

Fuerzas:
la misma información se presenta de distintas formas,
cambios en los datos deben reflejarse en la interfaz inmediatamente,
las interfaces deben modificarse fácilmente, ojalá durante la ejecución,
distintas interfaces portables no deben afectar la operación esencial.
 Modelo-Vista-Control (MVC)

Solución:
MVC divide la aplicación en Cada view tiene asociada un
procesamiento, input y output. controlador. El controlador
recibe eventos como input
El modelo representa la
(movimientos del mouse,
funcionalidad y los datos
activación de botones) y los
esenciales, y es
traduce a solicitudes de
independiente de la
servicios del modelo o la view.
representación en las
interfaces. El usuario interactúa con el
modelo solamente a través de
La view obtiene datos del modelo
controladores.
y los despliega para el
usuario.
 Modelo-Vista-Control (MVC)

Estructura:

Modelo View

encapsula la información esencial y despliega los datos para el

exporta procedimientos que usuario;
realizan procesamiento específico tienen procedimientos de
de la aplicación; actualización para recibir
provee funciones para que las views nuevos datos.
accedan a la información; Controlador
el mecanismo de cambio-propagación existe un controlador para cada
mantiene informados a las views y view;
a los controladores dependientes.
recibe los inputs de una view
como eventos y los
interpreta.
MVC: Estructura del Ejemplo

Torta
El modelo guarda los votos
acumulados para cada
partido político y permite Controlador_Tr
que las views accedan a los
números de votos.
Hay varias views: gráfico de Controlador_Ba Base de votos
barras, de torta o tabla.

Barras Controlador_Tb

Tabla
MVC: Dinámica

Escenario I: Input del usuario cambia el modelo y gatilla

el mecanismo de cambio-propagación.

Controlador Modelo View

evento servicio notificación desplegar

actualizar

obtener datos
actualizar
obtener datos
Modelo-Vista-Control (MVC)

Implementación:

Separar la funcionalidad esencial Implementar:

de la interacción humano-
computador.
Implementar el mecanismo de
cambio-propagación.
Diseñar e implementar las views.
Diseñar e implementar los
controladores.
Diseñar e implementar la relación
entre views y controladores.
La inicialización del MVC completo,
La creación de dinámica de views,
La controladores que capturan
diferentes eventos,
La infraestructura jerárquica para
views y controladores,
La más desacoplamiento de las
dependencias del sistema.
 Modelo-Vista-Control (MVC)
Consecuencias:
Beneficios:
múltiples views para el mismo
modelo,
views sincronizadas,
views y controladores
intercambiables.
Desventajas:
mayor complejidad,
excesivos cambios potenciales,
relación estrecha entre views y
controladores,
gran acoplamiento entre views y
controladores con el modelo,
ineficiencia en el acceso a los datos
desde la view,
cambios inevitables a las views y
controladores al portarlos,
difícil usar MVC con herramientas
gráficas modernas.
Modelo-Vista-Control

Utiliza los siguientes patrones:

Observer
Composite
Strategy
Decorator
Factory method
... Todos ellos son patrones de diseño.
Presentación-Abstracción-Control (PAC)

El patrón de arquitectura PAC define una estructura

jerárquica de agentes cooperativos. Cada agente es
responsable de un aspecto específico de la
funcionalidad de la aplicación y está compuesto por
tres componentes: presentación-abstracción-control.
Esta subdivisión separa los aspectos de HCI de los
agentes, del núcleo funcional de cada uno y de los
mecanismos de comunicación con otros agentes.
Presentación-Abstracción-Control (PAC)
Ejemplo: Consideremos un Sist. de Información Electoral.
- Ofrece una hoja de cálculo para el ingreso de datos
- Ofrece varios tipos de tablas y de gráficos para representar los
distintos resúmenes de la información almacenada.
- Los usuarios interactúan con el software a través de la interfaz
gráfica.
90
80
70
60
50
Este
40
Oeste
30
Norte
1tr. 2tr. 3tr. 4tr. 20
10
Este 20 25 90 20 0
1er 2do 3er 4to
Oeste 30 38 32 32 trim. trim. trim. trim.
Norte 47 47 45 45
2tr
4tr
Usuario Hoja de Cálculo 1tr
3tr
Presentación-Abstracción-Control (PAC)

Ejemplo (cont.):
- Diferentes versiones, adaptan la interfaz de usuario a necesidades
específicas, por ej., para ver las bancas del parlamento en función
de los partidos políticos.

Contexto: Desarrollo de sistemas interactivos con la

ayuda de agentes.

Problema: Cómo organizar el conjunto de agentes que

forman parte de un sistema interactivo, para que
funcionen en forma integrada.
 Presentación-Abstracción-Control

Fuerzas:
- Los agentes normalmente mantienen su estado y sus
datos, sin embargo tienen que cooperar y trabajar en
conjunto.
- Los agentes proveen su propia interfaz de usuario pues
cada uno tiene una cierta interacción prevista con el
usuario. Sin embargo, las modalidades de interacción
deben ser similares para que la HCI del producto sea
homogénea.
- Separar la presentación, de la funcionalidad, para que los
cambios en la interfaz no afecten demasiado al resto del
sistema. De todos modos la presentación y la funcionalidad
deben tener parámetros de acoplamiento aceptables.
 Presentación-Abstracción-Control
Solución:
- Organizar la estructura del sistema, jerárquicamente, según 3
niveles de agentes: alto nivel, intermedio y bajo nivel.
- Los agentes de alto nivel proveen el núcleo de la
funcionalidad del sistema. Este tipo de agente es quien
coordina y estructura la funcionalidad del sistema (menúes,
barras de herramientas, etc).
- Los agentes de bajo nivel representan conceptos
autocontenidos, sobre los cuales los usuarios del sistema
actúan. Típicamente estos agentes soportan las operaciones
de los usuarios.
- Los agentes intermedios representan combinaciones o
relaciones entre agentes de bajo nivel. Por ejemplo, este tipo
de agentes puede representar diversas vistas sobre los datos.
 Presentación-Abstracción-Control

Solución:
- Ejemplo: veamos un sistema de información electoral.
Repositorio

Alto nivel
Acceso a Datos

Controlador
Intermedio
de Vistas

Hoja de Gráfico Gráfico Gráfico

Cálculo Torta Líneas Barras
 Presentación-Abstracción-Control

Solución:
- Cada uno de los agentes es responsable de una parte de la
funcionalidad de la aplicación y contiene 3 componentes:
presentación, abstracción y control.
- La presentación provee el aspecto visible del agente.
- La abstracción provee el modelo de datos del agente y las
operaciones para operar con estos datos.
- El control conecta los componentes de presentación y de
abstracción, y le agrega la funcionalidad necesaria para
comunicarse con otros agentes.
 Presentación-Abstracción-Control
Estructura: cada agente representado en la jerarquía
tiene la siguiente estructura.

Controlador de Vistas

Control Presentation
Abstraction
InteractionData
BarData PresentationData
SendMsg
SetChartData Update
ReceiveMsg
GetChartData Open
GetData
Close
Zoom
Print
Agente Graficador de Barras
 Presentación-Abstracción-Control
Dinámica: para cada escenario que sea representativo, es
necesario definir la dinámica de las clases que forman
parte de la estructura. Definir al menos un par de
escenarios.
Consecuencias:
- Beneficios: Separación de conceptos, soporte para el
cambio y la extensión, soporte multitarea.
- Complicaciones: Incrementa la complejidad del sistema,
presenta problemas de eficiencia y de aplicabilidad,
involucran componentes de control complejos.
 Arquitectura de maquinas virtuales
una máquina virtual es un software que simula un sistema de
computación y puede ejecutar programas como si fuese una
computadora real.

Este software en un principio fue definido como "un duplicado

eficiente y aislado de una máquina física". La acepción del término
actualmente incluye a máquinas virtuales que no tienen ninguna
equivalencia directa con ningún hardware real.
Arquitectura de maquinas virtuales
 Arquitectura de maquinas virtuales
 Desarrolladas a finales de los 60.
 Usadas desde entonces en entornos mainframe.
 Ignoradas en máquinas monousuario hasta finales de los90.
 Popularidad recuperada debido a:
 Importancia creciente de aislamiento y seguridad en sistemas
modernos.
 Fallos en seguridad y fiabilidad en sistemas operativos.
 Comparticiónde un computador por varios usuarios.
 Gran incremento en prestaciones de procesadores.
 Sobrecarga de MMV’s más aceptable
 Arquitectura de maquinas virtuales
 Desarrolladas a finales de los 60.
 Usadas desde entonces en entornos mainframe.
 Ignoradas en máquinas monousuario hasta finales de los90.
 Popularidad recuperada debido a:
 Importancia creciente de aislamiento y seguridad en sistemas
modernos.
 Fallos en seguridad y fiabilidad en sistemas operativos.
 Comparticiónde un computador por varios usuarios.
 Gran incremento en prestaciones de procesadores.
 Sobrecarga de MMV’s más aceptable
“Somos lo que hacemos día a día. De modo que
la excelencia no es un acto sino unhábito”
Aristóteles