ARQUITECTURA DE

SOFTWARE

Definición de Arquitectura de Software

• David Garlan y Mary Shaw, en su libro "An introduction to Software Architecture",

señalan que la Arquitectura es un nivel de diseño que hace foco en aspectos "más
allá de los algoritmos y estructuras de datos de la computación; el diseño y
especificación de la estructura global del sistema es un nuevo tipo de problema".

• Software Architecture in Practice, Second Edition By Len Bass, Paul Clements, Rick
Kazman - “Una arquitectura es una descripción de las estructuras del sistema, de
las cuales hay varias (descomposición de módulos, proceso, implementación,
capas, etc.). La arquitectura es el primer artefacto que se puede analizar para
determinar qué tan bien se están logrando sus atributos de calidad, y también
sirve como modelo del proyecto. Una arquitectura sirve como vehículo de
comunicación, es la manifestación del diseño más antiguo para toma de
decisiones, y es una abstracción reutilizable que se puede transferir a nuevos
sistemas. Estas son las cosas que queremos decir cuando usamos la palabra
arquitectura.”

• La norma ISO/IEC/IEEE 42010:2011 establece requisitos para describir la

arquitectura de sistemas y software a través de una convención, terminología
común y mejores prácticas de Diseño y Descripción de Arquitectura. En este
contexto, la norma define la Arquitectura como los “conceptos fundamentales o
propiedades de un sistema en su entorno, materializados en sus elementos,
relaciones y en los principios de su diseño y evolución”. Al definirse la
Arquitectura como “concepto” se refiere a la concepción o ideación y como
“propiedad” que la “Arquitectura en sí misma es un atributo del sistema.
 • la definición general que propone el Instituto de Ingeniería de Software (SEI, por
sus siglas en inglés).

“La arquitectura de software de un sistema es el conjunto de estructuras necesarias

para razonar sobre el sistema. Comprende elementos de software, relaciones entre
ellos, y propiedades de ambos.” (Bass, Clements y Kazman, 2012).

• Una definición reconocida, La AS es, a grandes rasgos,

“una vista del sistema que incluye los componentes principales del mismo, la conducta
de esos componentes según se la percibe desde el resto del sistema y las formas en que
los componentes interactúan y se coordinan para alcanzar la misión del sistema.”
Es decir, la arquitectura brinda una visión global del sistema. Esto permite entenderlo,
organizar su desarrollo, plantear la reutilización del software y hacerlo evolucionar.

Se puede ver que la noción clave de la arquitectura es la organización y está relacionada

con aspectos de rendimiento, usabilidad, reutilización, limitaciones económicas y
tecnológicas.

La arquitectura de software también se relaciona con el diseño, pues, es una forma de

diseño de software que se manifiesta tempranamente en el proceso de creación de un
sistema.
La arquitectura se encuentra en un nivel de abstracción por encima del diseño de software
que se concentra en el modelado de abstracciones de más bajo nivel. Las interacciones
entre componentes en la arquitectura están en relación con un protocolo de alto nivel,
mientras que las del diseño conciernen a interacciones de tipo procedural. A medida que
la arquitectura de alto nivel se refina, sus puntos de conexión pierden grado de
abstracción, distribuyéndose así a través de los elementos arquitectónicos de más bajo
nivel, resultando en la transformación de la arquitectura en diseño. La arquitectura es algo
más integrado que la suma del análisis por un lado y el diseño por el otro.

Se ocupa de componentes y no de procedimientos; de las interacciones entre esos

componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes
y las interacciones y no de los algoritmos, los procedimientos y los tipos.

Se considera arquitectura de software como la descomposición de un sistema de nivel

superior en cada uno de sus componentes principales, las interfaces y su comunicación
(Garlan & Shaw, 1994a). De esta forma se define la arquitectura de software como el
análisis profundo de la construcción de los componentes, interfaces y comunicación que
tiene un sistema de información siguiendo un estilo de software específico.

“Una arquitectura es el conjunto de decisiones importantes sobre la organización de un

sistema de software, la selección de los elementos estructurales y sus interfaces por los
cuales el sistema está compuesto, junto con su comportamiento como es especificado en
las colaboraciones entre estos elementos, la composición de estos elementos estructurales
y de comportamiento en subsistemas progresivamente más grandes, y el estilo de
arquitectura que guía a esta organización (estos elementos y sus interfaces, sus
colaboraciones y su composición).” ( Booch, Rumbaugh y Jacobson en UML User Guide)

Arquitectura del software

¿Qué es arquitectura de software? - Introducción a la arquitectura # 1

Hablemos de Arquitectura de Software

Qué NO es la Arquitectura de SOFTWARE.

• La arquitectura y el diseño son la misma cosa

• La arquitectura y la infraestructura son la misma cosa
• “Mi tecnología favorita” es la arquitectura
• Una buena arquitectura es el trabajo de un único arquitecto
• La arquitectura es chata… un diagrama será suficiente
• La arquitectura es sólo la estructura
• La arquitectura del sistema precede a la arquitectura del software
• La arquitectura no puede ser medida y validada
• La arquitectura es una Ciencia
• La arquitectura es un Arte
• La arquitectura de software NO es la arquitectura del Sistema (o de la
computadora)
• La arquitectura de software NO es una vista de la funcionalidad
• La arquitectura de software NO es un dibujo conceptual de cajas y flechas.
• Diseño de algoritmos.
• Diseño de estructuras de datos.

El ciclo de desarrollo de la arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodología que se
utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo,
que precede a la construcción del sistema, está dividido en las siguientes etapas:
requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades
relacionadas con el desarrollo de la arquitectura de software generalmente forman parte
de las actividades definidas dentro de las metodologías de desarrollo.

1. Requerimientos.

La etapa de requerimientos se enfoca en la captura, documentación y priorización de

requerimientos que influencian la arquitectura. Los atributos de calidad juegan un papel
preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos.
Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos
son los requerimientos funcionales primarios y las restricciones.

Requerimiento: es una especificación que describe alguna funcionalidad, atributo

o factor de calidad de un sistema de software. Puede describir también algún
aspecto que restringe la forma en que se construye ese sistema.

2. Diseño.

La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la

más compleja. Durante esta etapa se definen las estructuras que componen la
arquitectura. La creación de estas estructuras se hace en base a patrones de diseño,
tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante
todo satisfacer los requerimientos que influencian a la arquitectura.

3. Documentación.

Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros

involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces
depende de que dicho diseño sea documentado de forma apropiada. La documentación
de una arquitectura involucra la representación de varias de sus estructuras que son
representadas a través de distintas vistas. Una vista generalmente contiene un diagrama,
además de información adicional, que apoya en la comprensión de dicho diagrama.
 4. Evaluación.

Dado que la arquitectura de software juega un papel crítico en el desarrollo, es

conveniente evaluar el diseño una vez que este ha sido documentado con el fin de
identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una
actividad que se puede realizar de manera temprana (aún antes de codificar), y que el
costo de corrección de los defectos identificados a través de la evaluación es mucho
menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido
construido.

• Implementación de la arquitectura.

Una vez establecida la arquitectura, se construye el sistema. Durante esta etapa es

importante evitar que ocurran desviaciones respecto del diseño definido por el arquitecto.

Objetivos de la Arquitectura del software.

• Diseño preliminar o de alto nivel.

Organización a alto nivel del sistema, incluyendo aspectos como la descripción

y análisis de propiedades relativas a su estructura y control global.

• Los protocolos de comunicación y sincronización utilizados.

• La distribución física del sistema y sus componentes.
• Otros aspectos relacionados con el desarrollo del sistema y su evolución y
adaptación al cambio. (patrones, estilos, costos).

composición, reconfiguración, reutilización, estabilidad... (criterios de calidad

aplicables)

Patrones
Uno de los conceptos fundamentales de diseño son los patrones, que son soluciones
conceptuales a problemas recurrentes a la hora de diseñar.

Los patrones ayudan a construir sobre la experiencia colectiva de ingenieros de software

experimentados. Estos capturan la experiencia existente y que ha demostrado ser exitosa
en el desarrollo de software, y ayudan a promover las buenas prácticas de diseño. Cada
patrón aborda un problema específico y recurrente en el diseño o implementación de un
software.

Un aspecto importante a resaltar es que los patrones son soluciones conceptuales, esto
significa que no pueden usarse de forma directa, sino que deben ser “instanciados”, es
decir, adecuados al contexto y al problema específico que se busca resolver.

Un patrón arquitectónico particular, o una combinación de éstos, no es una arquitectura

de software completa, es un framework estructural para un sistema de software que
debe ser luego especificado y refinado. Esto incluye la tarea de integrar la funcionalidad
de las aplicaciones con el framework y detallar sus componentes y relaciones.

Dentro de los patrones arquitectónicos se pueden citar:

1. Layers
2. Pipes and Filters
3. Blackboard,
4. Broker.
5. Model-View–Controller.
6. Presentation– Abstraction–Control.
7. Microkernel y Reflection.

Cliente-servidor (Arquitectura de dos capas):

Actualmente existen muchos sistemas de información cuya arquitectura se basa en la
denominada dos capas, las cuales solo cuentan con los siguientes niveles o capas:

• Nivel de aplicación.
• Nivel de la base de datos
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, es 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.

Características

En esta arquitectura el remitente se conoce como cliente, el cual es quien realiza lo

siguiente:

• Inicia solicitudes o peticiones.

• Debe esperar y recibir respuestas del servidor.
• Puede conectarse a varios servidores.
• Por lo general interactúa con el usuario final a través de una interfaz gráfica.
En cuanto al receptor de la solicitud enviado por el cliente se conoce como servidor, el
mismo se caracteriza por:
• Desempeñan un papel pasivo en la comunicación, deben esperar a que lleguen las
solicitudes.
• Al recibir una solicitud, la misma es procesada y posteriormente envían la
respuesta.
• Generalmente pueden aceptar las conexiones de varios clientes a la vez.
• No es frecuente, la interacción directa con el usuario final
ARQUITECTURA TUBOS Y FILTROS. (Pipes and Filters).

El patrón de arquitectura Tuberías y Filtros proporciona una estructura para los sistemas
de flujo de proceso de datos. Cada paso del proceso se encapsula en un componente de
filtro. Los datos se pasan a través de tubos entre filtros adyacentes. Recombinar filtros le
permite construir familias de sistemas relacionados.

Estructura: El patrón de arquitectura Tubos y Filtros está conformado por:

• Tubo: Es el conector que pasa los datos de un filtro al siguiente. Se trata de un

flujo unidireccional de datos.

• Filtro: Es el encargado de filtrar o transformar los datos que recibe a través de las
tuberías.
− Enriquece los datos computando y agregándole información,
− los refina concentrando o extrayendo la información y
− los transforma entregándolos en alguna otra representación.

• fuente de datos (Entrada): También llamado productor es el origen de datos.

Puede ser archivos, bases de datos, o dispositivos de entrada.
El patrón Pipes and Filters tiene las siguientes ventajas:

• No son necesarios archivos intermedios, pero es posible su utilización. Es posible

calcular resultados usando programas separados sin pipes, guardando los
resultados intermedios en archivos.
• Flexibilidad por el intercambio de filters. Los filters tienen una interfaz simple que
permite su intercambio fácilmente dentro del procesamiento del pipeline.
• Flexibilidad por recombinación. Este es el mayor beneficio, combinado con la
reusabilidad de los componentes filters, permitiendo la creación de nuevos
procesos pipelines reestructurando los filters o agregando uno nuevo.
• Reusabilidad. Permite la recombinación de filters facilitando el reusó de sus
componentes.
• El prototipado rápido de los pipelines. Las Ventajas precedentes hacen esto más
fácil para el prototipo de un sistema de procesamiento de datos de los filters
existentes.
• Eficiencia del procesamiento en paralelo. Si cada filter en un pipeline produce y
consume datos incrementalmente pueden realizar sus funciones en paralelo.

desventajas:

• El costo de transferir datos entre filters puede ser relativamente alto comparado
con el costo de realizar cómputos en un solo filter.
• Algunos filters consumen todas sus entradas antes de producir cualquier salida.
• Manejo de errores. El manejo de errores es una gran debilidad del patrón Pipes
and Filters. Se debería por lo menos definir una estrategia común para el reporte
de errores y usarse a lo largo de todo el sistema.

Ejemplos:
Sistemas SCADA.

Los sistemas SCADA son utilizados por industrias y empresas de los sectores público y
privado para una gran variedad de procesos. Funcionan bien en diferentes tipos de
empresas porque puede abarcar desde configuraciones simples hasta instalaciones
grandes y complejas.

SCADA, un acrónimo de Supervisory Control And Data Acquisition (Supervisión, Control y

Adquisición de Datos), es un sistema de elementos de software y hardware que permite a
las industrias:

• Controlar los procesos industriales localmente o a distancia

• Monitorizar, recopilar y procesar datos en tiempo real
• Interactuar directamente con dispositivos como sensores, válvulas, bombas,
motores, señales de tráfico, etc., a través del software de interfaz hombre-
máquina (HMI)
• Grabar eventos en un archivo de registro

Los sistemas de software scada son cruciales para los procesos industriales, ya que ayudan
a mejorar en eficiencia, procesar datos para tomar decisiones más inteligentes, y a avisar
de los problemas del sistema para ayudar a reducir el tiempo de inactividad.
Arquitectura en Capas.

Este estilo de arquitectura se basa en jerarquías donde las capas superiores son servidas
por las inferiores y las inferiores proveen servicios a las superiores. Los componentes son
llamados capas y los conectores son llamados protocolos los cuales interactúan entre las
capas. Dos ejemplos de este estilo de arquitectura son los Sistemas Operativos y los
protocolos de comunicación en capas (Garlan & Shaw, 1994a).
Las capas son agrupaciones horizontales lógicas de componentes de software que forman
la aplicación o el servicio. Nos ayudan a diferenciar entre los diferentes tipos de tareas a
ser realizadas por los componentes, ofreciendo un diseño que maximiza la reutilización y,
especialmente, la mantenibilidad. En definitiva, se trata de aplicar el principio de
„Separación de Responsabilidades‟ (SoC - Separation of Concerns principle) dentro de
una Arquitectura. Cada capa lógica de primer nivel puede tener un número concreto de
componentes agrupados en sub-capas. Dichas sub-capas realizan a su vez un tipo
específico de tareas.

Al identificar tipos genéricos de componentes que existen en la mayoría de las soluciones,

podemos construir un patrón o mapa de una aplicación o servicio y usar dicho mapa
como modelo de nuestro diseño.

El dividir una aplicación en capas separadas que desempeñan diferentes roles y

funcionalidades, nos ayuda a mejorar el mantenimiento del código; nos permite también
diferentes tipos de despliegue y, sobre todo, nos proporciona una clara delimitación y
situación de dónde debe estar cada tipo de componente funcional e incluso cada tipo de
tecnología. (Guía de Arquitectura N-Capas Orientada al Dominio con .NET 4.0)

Principios fundamentales:
Los principios aplicables en el diseño para usar este estilo de arquitectura son los
siguientes:
• Abstracción: Separa la vista del modelo como un todo mientras que suministra
suficiente detalle que pudiera ayudar a entender las relaciones entre capas.
• Encapsulamiento: El diseño no hace exaltaciones acerca de tipos de datos,
métodos, propiedades o implementación.
• Funcionalidad claramente definida: La separación entre la funcionalidad de cada
capa es definido, lo cual conlleva a que capas superiores como la capa de
presentación envíen comandos a las capas inferiores como la capa de negocios y la
capa de datos, haciendo que los datos puedan fluir hacia y desde las capas en
cualquier sentido.
• Alta cohesión: Cada capa tiene funcionalidad que se encuentra relacionadas
directamente a la tarea de dicha capa.
• Reutilizable: Las capas inferiores no tienen ninguna dependencia con las capas
superiores, permitiéndoles ser reutilizables en otros escenarios.
• Desacople: La comunicación entre las capas está basada en la abstracción lo que
provee un desajuste entre las capas.
patrón arquitectónico Blackboard
El patrón arquitectónico Blackboard es útil para los problemas en los cuales no se conoce
ninguna estrategia de solución determinística. En Blackboard varios subsistemas
especializados asocian sus conocimientos para construir una posible solución parcial o
aproximada. Habitualmente utilizado en sistemas expertos, multiagente y basados en el
conocimiento.

Estructura de Blackboard

El sistema se divide en un componente llamado pizarra, una colección de fuentes de

conocimiento, y un componente de control.

La pizarra: es el almacenamiento central de datos que guarda también los elementos del
espacio de solución y el control de datos. Proporciona una interfaz que habilita a todas las
fuentes de conocimiento para leer y escribir en ella.

Las fuentes de conocimiento: son subsistemas separados e independientes que

resuelven aspectos específicos del problema global y modelan el dominio del mismo.
Ninguno de ellos puede resolver en forma aislada la tarea del sistema.

Una solución se construye integrando los resultados de varias fuentes de conocimiento.

Ellas sólo leen y escriben en la pizarra.
Cada fuente de conocimiento es responsable de conocer las condiciones bajo las cuales
puede contribuir a una solución, evaluando el estado actual del proceso de la solución
para determinar si puede hacer una contribución, y producir un resultado que puede
causar un cambio en el contenido de pizarra.

El componente de control: ejecuta un loop que monitorea los cambios en la pizarra y

decide qué acción tomará luego. Establece las evaluaciones de la fuente de conocimiento
y activaciones de acuerdo a una estrategia de aplicación conocida. La base para esta
estrategia es el dato sobre la pizarra, que ayuda a la toma de decisiones de control. Sus
resultados se llaman datos de control y también se ponen en la pizarra.

Ventajas de Blackboard.

• Experimentación. En dominios en que no existe alguna posible solución y una

búsqueda completa del espacio de la solución no es factible, el patrón Blackboard
experimenta con la mayor cantidad posible de algoritmos diferentes, y también
permite intentar con diferentes heurísticas de control.
• Cambiabilidad y mantenibilidad. La arquitectura Blackboard soporta la
cambiabilidad y mantenibilidad porque las fuentes de conocimiento individuales,
el algoritmo de control y la estructura de datos central están estrictamente
separados.
• Reusabilidad. Las fuentes de conocimiento son independientes para ciertas
tareas. Una arquitectura Blackboard ayuda haciéndolas reusables. Los requisitos
previos para reusar son que la fuente de conocimiento y el sistema Blackboard
subyacente entiendan el mismo protocolo y datos.
• Tolerancia a fallos y robustez. En una arquitectura Blackboard todos los
resultados son sólo hipótesis. Sólo sobrevivirán aquellas que son fuertemente
soportadas por los datos y otras hipótesis.

Desventajas de Blackboard:

• Dificultad de testeo. Los cómputos de este patrón no siguen un algoritmo

determinístico, por lo tanto, sus resultados no son a menudo reproducibles.
Además, hipótesis erróneas son parte del proceso de solución.
• No se garantiza ninguna buena solución. Normalmente puede resolver
correctamente sólo un cierto porcentaje de las tareas dadas.
• Dificultad de establecer una buena estrategia de control. La estrategia de control
no puede diseñarse de una manera íntegra, y requiere un acercamiento
experimental. o Baja eficiencia. Padece el exceso computacional del rechazo de las
hipótesis erróneas. o Alto esfuerzo de desarrollo. La mayoría de estos sistemas
 toman años para evolucionar. Se atribuye esto a los dominios mal estructurados
del problema y una programación basada en prueba/error para definir estrategias
de control y fuentes de conocimiento.
• No soporta paralelismo. La arquitectura Blackboard no provee la ejecución en
paralelo. El acceso concurrente a los datos centrales en la pizarra se debe
sincronizar.

Ejemplos:

• Sistema de Inteligencia Ambiental: La información en un sistema de IAm

(Inteligencia Ambiental) es de naturaleza diversa. Los datos sin procesar de los
sensores se agregan para crear información abstracta, que puede ser procesada
por componentes que observan sus cambios para decidir qué acciones tomar. Este
proceso involucra las siguientes tareas: encontrar las fuentes de información
disponibles y sus tipos, reunir los datos proporcionados por estas fuentes, facilitar
la fusión (agregación y derivación) de los fragmentos de información, y actualizar la
representación de este contexto para que sea usada por aplicaciones. Fernández
de Alba López de Pablo J.M - Arquitectura de pizarras distribuidas para sistemas de
Inteligencia Ambiental- Departamento de Ingeniería del Software e Inteligencia
Artificial - Facultad de Informática Universidad Complutense de Madrid- Mayo
2014.
• Jordi Ribera Altimir Grupo 2. documento inteligencia Ambiental.
• https://mamilab.eu/
• C4ISTAR - Inteligencia, Vigilancia, Adquisición de Objetivos, Reconocimiento (Intelligence,
Surveillance, Target Acquisition, Reconnaissance).

MVC (Modelo-Vista-Controlador)

El MVC es un patrón de diseño arquitectónico de software, que sirve para clasificar la

información, la lógica del sistema y la interfaz que se le presenta al usuario. En este tipo
de arquitectura existe un sistema central o controlador que gestiona las entradas y la
salida del sistema, uno o varios modelos que se encargan de buscar los datos e
información necesaria y una interfaz que muestra los resultados al usuario final. Es muy
usado en el desarrollo web porque al tener que interactuar varios lenguajes para crear un
sitio es muy fácil generar confusión entre cada componente si estos no son separados de
la forma adecuada. Este patrón permite modificar cada uno de sus componentes si
necesidad de afectar a los demás.
Componentes

Modelo: este componente se encarga de manipular, gestionar y actualizar los datos. Si se

utiliza una base de datos aquí es donde se realizan las consultas, búsquedas, filtros y
actualizaciones.

Vista: este componente se encarga de mostrarle al usuario final las pantallas, ventanas,
páginas y formularios; el resultado de una solicitud. Desde la perspectiva del programador
este componente es el que se encarga del frontend; la programación de la interfaz de
usuario si se trata de un aplicación de escritorio, o bien, la visualización de las páginas web
(CSS, HTML, HTML5 y Javascript).

Controlador: este componente se encarga de gestionar las instrucciones que se reciben,

atenderlas y procesarlas. Por medio de él se comunican el modelo y la vista: solicitando
los datos necesarios; manipulándolos para obtener los resultados; y entregándolos a la
vista para que pueda mostrarlos.

Este patrón es uno de los más usados, en la actualidad se puede encontrar tanto en
pequeños como en grandes sistemas.

Utilizado en múltiples frameworks

• Java Swing
• Java Enterprise Edition (J2EE)
• XForms (Formato XML estándar del W3C para la especificación de un modelo de
proceso de datos XML e interfaces de usuario como formularios web)
• GTK+ (escrito en C, toolkit creado por Gnome para construir aplicaciones gráficas,
inicialmente para el sistema X Window)
• ASP.NET MVC Framework (Microsoft)
• Google Web Toolkit (GWT, para crear aplicaciones Ajax con Java)
• Apache Struts (framework para aplicaciones web J2EE)
• Ruby on Rails (framework para aplicaciones web con Ruby)