DDRS_U2_Contenido

Vista previa del material en texto

Desarrollo de Software 
4o semestre 
 
Programa de la asignatura: 
Diseño y arquitectura de software 
 
 
Unidad 2. Elementos de diseño de la arquitectura de 
software 
 
Clave: 
 
Ingeniería: 
15142424 
TSU: 
/ 16142525 
 
 
Universidad Abierta y a Distancia de México 
 
 
 
México, Ciudad de México, agosto del 2023 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 2 
 
 
 
 
Índice 
Unidad 2. Elementos de diseño de la arquitectura de software .............................. 3 
Presentación de la unidad ...................................................................................... 3 
Logros .................................................................................................................... 3 
Competencia específica ......................................................................................... 4 
2.1. Estilos y patrones arquitectónicos .................................................................... 4 
2.1.2 Enfoque ....................................................................................................... 10 
2.2. Categorías de estilos arquitectónicos ............................................................ 13 
2.2.1 Basado en componentes.............................................................................. 14 
2.2.2 Capas .......................................................................................................... 16 
2.2.3 Cliente/servidor ............................................................................................ 18 
2.2.4 Orientado a objetos ...................................................................................... 19 
2.2.5 Tuberías y filtros .......................................................................................... 21 
Cierre de la unidad ............................................................................................... 23 
Fuentes de consulta ............................................................................................. 23 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 3 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
Presentación de la unidad 
 
Figura 1.Arquitectura. Tomada de 
https://www.ibm.com/developerworks/ 
ssa/webservices/library/j- 
eaed10/figure1.jpg 
 
 
 
En esta segunda unidad revisarás de manera 
profunda los modelos y patrones de arquitectura y 
su influencia sobre la arquitectura de software, los 
tipos que existen y las características de cada 
modelo; asimismo, conocerás las distintas 
propuestas que existen en la industria del desarrollo 
de software. 
 
Los temas desarrollados en la unidad te ayudarán a 
identificar el modelo adecuado a aplicar para una 
determinada problemática en el desarrollo de software. 
 
Finalmente distinguirás diferencias primordiales en los estándares más aplicados y 
extendidos en la industria del desarrollo de software. 
¡Bienvenido a la unidad 2! 
 
 
Logros: 
 
 
Al término de esta unidad lograrás: 
• Analizar y distinguir los fundamentos de los patrones y estilos 
arquitectónicos. 
• Analizar las categorías de estilos aplicables a la arquitectura de 
software. 
• Proponer la solución preliminar de la arquitectura de software sobre la base de los 
requerimientos del usuario. 
https://www.ibm.com/developerworks/ssa/webservices/library/j-eaed10/figure1.jpg
https://www.ibm.com/developerworks/ssa/webservices/library/j-eaed10/figure1.jpg
https://www.ibm.com/developerworks/ssa/webservices/library/j-eaed10/figure1.jpg
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 4 
 
 
 
Competencia específica 
• Aplica un estilo de diseño para generar una propuesta de modelo 
arquitectónico que permita el diagnóstico de información de los 
usuarios mediante el análisis y uso de herramientas de diferentes 
tipos y la descripción del comportamiento del sistema planteado en 
respuesta a un caso concreto. 
 
 
 
2.1. Estilos y patrones arquitectónicos 
 
Los estilos y patrones arquitectónicos son una forma clara de plasmar la solución de un 
problema mediante el uso de arquitectura de software, se usa también para comunicar un 
diseño arquitectónico a las etapas posteriores del desarrollo de software. 
 
 
 
 
De las definiciones anteriores se puede deducir que ambos conceptos llevan a formar un 
estilo propio de cómo hacer las cosas para poder explicar un sistema o una realidad 
compleja. Entonces, se puede definir al estilo como “cada una de las distintas formas de 
realizar algo”. Esta consecución de definiciones y deducciones nos lleva a comprender lo 
básico de los estilos arquitectónicos o patrones arquitectónicos. 
 
 
En el sentido estricto de la palabra, un patrón es “un modelo que se toma como 
muestra para reproducir un objeto o concepto igual” (RAE, 2012a). Para 
complementar la definición de un patrón se tiene que, un modelo “representa una 
realidad o un sistema que se distinguen por ser complejos, generalmente la 
representación con el uso de un lenguaje matemático formal” (RAE, 2012b). 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 5 
 
 
 
En los últimos años la sistematización de los estilos arquitectónicos ha sido uno de los temas 
más recurrentes; sin embargo, solo en breves ocasiones la literatura técnica especializada 
sobre patrones arquitectónicos realmente hace un buen análisis del vínculo innegable entre 
estilos y patrones. Suele decirse que están íntegramente comunicados y se deja muy poco 
clara la barrera de separación entre uno y otro, pero nadie se atreve a articular de forma 
sistemática y formal su relación. 
Para no seguir con discusiones que por ahora son interminables, se abordará el tema de 
estilos arquitectónicos que es semejante a un patrón arquitectónico; no obstante, una 
diferencia básica entre ellos es que las personas que trabajan con estilos se inclinan hacia 
un tratamiento que lleva una alta carga teórica, un enfoque académico y de abstracción 
mucho más elevado para su aplicación, mientras las personas que trabajan con patrones se 
inclinan por el diseño, lo práctico, la implementación en aspectos reales, el refinamiento y 
el código duro. 
 
 
2.1.1. Fundamentos 
 
Antes de siquiera pensar en definir lo que es un estilo arquitectónico, se debe entender cuál 
fue el origen. En los principios se detectó repetición en el comportamiento de las soluciones 
de arquitectura de software (AS) aplicadas a problemas similares. El número de apariciones 
del comportamiento fue limitado, pero repetible, y tomando como referencia la 
arquitectura en edificios reales, se les llamó estilos. Un estilo es una “clase” o “tipo” de 
arquitectura o piezas repetibles que se dieron con el andar de las cosas. No se debe hacer 
mucho esfuerzo por encontrar esas piezas, porque la misma práctica va otorgándolas. 
Cuando se han identificado de manera clara estas piezas (estilos) por sentido común y lógica 
se puede pensar en volver a utilizarlas en ambientes y situaciones parecidos a aquellos en 
los cuales surgieron. 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 6 
 
 
 
Desde su formulación inicial en 1992, junto con el nacimiento de la arquitectura de 
software, en sentido estricto por la IEEE se han ido generalizando, como una línea del 
tiempo progresiva con base en los avances tecnológicos las arquitecturas cliente-servidor, 
configuración en capas, basadas en componentes, en recursos (la Web) y en servicios (los 
Web Services). Recordemos que la importancia radica en que la teoría del arquitecto de 
software derive en la práctica de implementar los sistemas. 
 
En un estilo de la arquitectura de software se localizan tres tipos de elementos: de 
procesamiento (que transforman los datos), de datos (informacióna procesar) y de 
conexión (como llamadas a procedimientos almacenados, mensajes, etc.) además se 
enfatiza sobre las restricciones de estos elementos y sus relaciones posibles. 
 
Características de los estilos arquitectónicos 
 
Como ya se ha mencionado con anterioridad la arquitectura de software se encuentra aún 
en un proceso de consolidación. Las diferencias que se pudiesen localizar entre estilos y 
patrones arquitectónicos dependen en gran medida del enfoque dado por cada autor. Para 
efectos de estudio nos centraremos en las características enumeradas por los autores 
Reynoso (2004) y Taylor, Medvidovic y Dashofy (2009). 
La principal característica de un estilo arquitectónico es la comunicación de diseños. Una 
característica es un rasgo distintivo que sólo posee algo (un objeto, persona, animal, entre 
otros) o un grupo de ellos. Otras características que se pueden enumerar respecto a los 
estilos de diseño son: 
• Sirven para sintetizar estructuras de soluciones. 
• Pocos estilos abstractos encapsulan una enorme variedad de configuraciones 
concretas. 
• Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas 
ante diferentes conjuntos de requerimientos no funcionales. 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 7 
 
 
 
• Aplicable a un contexto de desarrollo dado. 
• Restringe decisiones de diseño arquitectónicas que son específicas a un sistema 
particular dentro de aquel contexto. 
• Constituye una forma primaria de caracterizar lecciones aprendidas en el diseño de 
software en base a la experiencia. 
Para el diseño de una arquitectura de software deben verificarse las características de los 
estilos arquitectónicos y realizar varias decisiones para la elección del estilo arquitectónico 
adecuado, tal como la funcionalidad. Aunado a decisiones en relación con la seguridad, 
rendimiento, etc., que en conjunto afectan a todo el desarrollo del sistema. El diseño debe 
indicar claramente los componentes básicos del sistema y su relación para implementar 
posteriormente la funcionalidad. No es un proceso de un solo paso, es iterativo, en el cual 
se van tomando las decisiones comprobables con el fin de minimizar los riesgos que se 
puedan presentar. 
Características de los patrones arquitectónicos 
 
Un patrón arquitectónico al igual que sucede con un estilo brinda los elementos necesarios 
para la trasformación del diseño de una arquitectura de software. “Cada patrón describe 
un problema que ocurre una y otra vez en un ambiente y luego se describe el núcleo de la 
solución a ese problema, de tal manera que se puede usar esa solución repetidamente” 
(Welicki, 2015) aunque esta definición fue realizada para la arquitectura de edificios aplica 
también y se toma como tal para arquitectura de software. Sus características son: 
• Codifica conocimiento específico acumulado por la experiencia en un dominio. 
• Un sistema bien estructurado está lleno de patrones. 
• Documentan la experiencia de diseño existente y que ha sido bien probada. 
• Identifican y especifican abstracciones que están por encima del nivel de las clases 
y las instancias o los componentes. 
• Se concentran en soluciones de diseño y sus relaciones con las que construir un 
componente de software. 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 8 
 
 
Además de la lista presentada, se debe tener en cuenta algo muy importante, cuando se 
trata de características de patrones de software no toda aquella solución que tenga un 
cierto parecido a ésta lo es. Deben hacerse pruebas (de compatibilidad entre soluciones, de 
similaridad, de homogeneidad, entre otras) a problemas que tienen las mismas premisas, y 
si es aplicable, se considerará un patrón. Sin embargo, deberá pasar además una serie de 
pruebas aplicadas única y particularmente a los patrones. Antes de estas pruebas, la 
mencionada solución no dejará de ser un patrón-primigenio. 
Cuando un patrón haya pasado el conjunto de pruebas que haya que aplicar, tendrá las 
siguientes características: 
 
Fuente: https://www.blogger.com/profile/10551413964496036547 
 
Otra característica necesaria de los patrones arquitectónicos, mas no suficiente, es la 
repetición, si no la tiene entonces no es un patrón. 
 
En términos formales se definirá que: 
• La repetición se considera una característica cuantitativa. 
• La utilidad y adaptabilidad son características cualitativas. 
 
 
• Solucionar un problema: si no puede hacer más allá de tener principios o 
estrategias abstractas, entonces no será patrón. 
• Ser un concepto probado: como el punto anterior, si no ofrecen soluciones 
plenamente demostrables, entonces no será patrón. 
• La solución no es obvia: un patrón busca soluciones a problemas complejos de 
forma que abstraen dentro de sí soluciones pequeñas para cada parte del 
problema o de forma indirecta. 
• Describe participantes y relaciones entre ellos: se describe de manera clara y 
detallada un sistema completo, no sólo módulos aislados. El nivel de 
complejidad puede crecer sin causar problema para el patrón arquitectónico. 
• El patrón tiene un componente humano significativo: la principal razón de 
fabricar (o diseñar) software es para facilitar el trabajo humano. 
http://www.blogger.com/profile/10551413964496036547
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 9 
 
 
Para poder comprobar la existencia o ausencia de estas características se proponen en 
diferentes textos algunas formas empíricas de poder hacerlo, pero no se tratarán en la 
presente asignatura. 
Diferencias entre estilos y patrones arquitectónicos 
 
En cuanto a los estilos y patrones arquitectónicos, los dos conceptos son similares, ambos 
definen una solución a un problema de software concreto y no siempre es posible identificar 
un límite bien definido. En un intento por establecer las diferencias detectables entre 
ambos se incluye el siguiente cuadro comparativo según lo indicado por los autores (Taylor, 
Medvidovic y Dashofy, 2009): 
 
Características Estilo arquitectónico Patrón arquitectónico 
 
 
 
 
Alcance 
 
Aplican a un contexto de 
desarrollo: 
• Sistemas altamente 
distribuidos 
• Sistemas intensivos en GUI 
Aplican a problemas de diseño 
específicos: 
• El estado del sistema debe 
presentarse en múltiples formas. 
• La lógica de negocio debe estar 
separada del acceso a 
los datos. 
 
 
Abstracción 
Son muy abstractos para producir 
un diseño concreto del sistema. 
Son fragmentos arquitectónicos 
parametrizados que pueden ser 
pensados como una pieza 
concreta de diseño. 
 
 
Relación 
Un sistema diseñado de acuerdo a 
las reglas de un único estilo puede 
involucrar el uso de múltiples 
patrones. 
Un único patrón puede ser aplicado a 
los lineamientos de múltiples estilos. 
Tabla 1. Diferencias entre estilos y patrones arquitectónicos 
Taylor, Medvidovic y Dashofy (2009). Software Architecture – Foundations, Theory and Practice. Wiley 
 
 
La base sobre la cual está formado cualquier sistema es una estructura que puede ser física 
o lógica. 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 10 
 
 
 
Esta estructura puede ser completamente nueva, respecto al problema que se quiera 
resolver, o estar tomando fundamentos de conocimientos aplicados antes a la resolución 
de problemas parecidos, en donde se esperan resultados similares, en tiempo y espacio 
similar; los patrones de estructura surgen cuando se cumplen las condiciones antes 
mencionadas. 
La aplicación formal de los patrones y estilos de estructura a una arquitectura de software 
debe hacerse de manera sistemática y organizada, no se puede resolver el problema al que 
el arquitecto se enfrenta con la sola aplicación de un patrón determinado. 
 
 
2.1.2 Enfoque 
Existen diferentestipos de estilos aplicables en la AS, los cuales se usan dependiendo de la 
naturaleza del problema a resolver; sirven para tomarlos como punto de partida, ya que se 
usan como andamiaje para construir la solución sobre una idea ya avanzada y no comenzar 
siempre la solución desde la nada. 
Tratar de hacer un catálogo detallado de los tipos de estilo sería una idea poco práctica, 
porque cada autor, e inclusive cada arquitecto, podrían dar una lista propia a su gusto. Por 
ello sólo se enumerarán las consideraciones primarias de la literatura técnica especializada 
sobre patrones arquitectónicos y se podrá tomar como una clasificación de primer orden. 
La enumeración primaria de la que se hace mención puede llevar a preguntarse: 
UNADM | DCEIT | DS | DDRS 11 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
¿Cuántos estilos existen? 
¿Cuáles son? 
¿Son suficientes? 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
La idea de organizar los estilos y sus tipos comenzó por la necesidad de hacer una distinción 
clara entre ellos, porque el número de patrones que se estaba conociendo llegó a ser tan 
alto que había siempre confusiones. De acuerdo con Reynoso y Kicillof (2004), la siguiente 
lista se puede tomar como una primera propuesta: 
• Arquitectura orientada a objeto. 
• Arquitectura de estados. 
• Arquitecturas de control de realimentación. 
• Arquitectura de tiempo real. 
• Modelo de diseño de descomposición funcional. 
• Modelo orientado por eventos. 
• Modelo de control de procesos. 
• Modelo de tabla de decisión. 
 
En un segundo acercamiento, al refinar la lista anterior, surge la necesidad de replantear la 
clasificación (combinando arquitecturas y modelos de diseño), llegando a la lista siguiente: 
UNADM | DCEIT | DS | DDRS 12 
 
 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Tubería-filtros. 
Organización de abstracción de datos. 
Invocación implícita. 
Sistemas en capas. 
Repositorios. 
Intérpretes orientados por tablas. 
Procesos distribuidos. 
Organizaciones programa principal-subrutina. 
Arquitecturas de software específicas de dominio. 
Sistemas de transición de estado. 
Sistemas de procesos de control. 
Estilos heterogéneos. 
Unidad 2. Elementos de diseño de la arquitectura de software 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Para escribir los acercamientos anteriores (el primero y su refinamiento) se tomó como 
base la información contenida en el material de Reynoso y Kicillof (2004). 
 
Es importante notar que las clasificaciones presentadas tienen un parecido amplio, debido 
a que ambas están sobre la base de listar estilos que se usan para poder expresar algún tipo 
de organización estructural claramente definido, además son parte sustantiva para los 
sistemas de software, porque éstos por definición basan su estructura en una organización 
jerárquica, que con los estilos arquitectónicos se puede detallar de manera práctica y clara, 
incluyendo sus subsistemas (como el software mismo en su definición más ortodoxa), qué 
y cuáles son los procesos que debe seguir (especifican responsabilidades y lineamientos 
para organizar las relaciones entre ellos). 
 
Ahora bien, han surgido distintas vertientes para la clasificación de los estilos, podemos 
localizar los modelos ya mencionados, así como más propuestas realizadas por Bass, 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 13 
 
 
Clemens, Kazman (Software Architectura in Practice), Fielding, Garlan y otros autores y de 
hecho si se presentaran más clasificaciones o estilos arquitectónicos se estaría dando 
vueltas sobre lo mismo, de tal forma que puede resumirse en la siguiente tabla: 
Categorías de tipos de estilos arquitectónicos 
Estilos de flujo de datos • Tuberías y filtros 
Estilos centrados en datos 
• Arquitecturas de pizarra o 
repositorio. 
 
Estilos de llamada y retorno 
• Modelo-vista-controlador (MVC) 
• Arquitecturas en capas 
• Orientado a objetos 
• Basada en componentes 
Estilos de código móvil 
• Arquitecturas de máquinas 
virtuales. 
Estilos heterogéneos 
• Sistemas de control de procesos 
• Arquitecturas basadas en atributos 
 
Estilos Peer-to-Peer 
• Arquitecturas basadas en eventos. 
• Orientadas a servicios 
• Arquitecturas basadas en recursos. 
Estilos derivados 
• C2 
• Objetos distribuidos 
Tabla 2. Categorías de estilos arquitectónicos 
Billy Reynoso, Architect Academy: Seminario de Arquitectura de Software, Universidad de Buenos Aires 
 
La serie de listas y categorías presentadas en el apartado actual permitirán tener una clara 
diferenciación entre los tipos de estilos y en dónde ubicarlos respecto del tipo de lógica que 
maneja. Otro punto para tomar en cuenta para la correcta clasificación son las 
características propias de cada tipo de estilo. 
 
A continuación, se describen los estilos que mayormente aparecen referidos en la literatura 
especializada de arquitectura de software o que aparecen con mayor frecuencia 
mencionados como categorías mayores del catálogo. 
 
 
 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 14 
 
 
 
2.2. Categorías de estilos arquitectónicos 
 
Existen varias categorías de estilos arquitectónicos de acuerdo con la información incluida 
en la tabla del subtema 2.1.2., estos estilos pueden verse como una herramienta para dar 
forma a la arquitectura de software, base para el desarrollo de la aplicación informática. 
Nos podemos topar que en algunas arquitecturas diseñadas no se aplique únicamente un 
estilo, sino que se combinan características de varios de ellos con el fin de obtener las 
ventajas individuales que proporcionen una indicación abstracta de la forma en que debe 
dividirse el sistema y de cómo estas partes deben de comunicarse entre ellas. A 
continuación de describen los estilos más representativos, de acuerdo con De La Torre, 
Zorrilla, Calvarro y Ramos (2010) así como Taylor, Medvidovic y Dashofy (2009). 
 
2.2.1 Basado en componentes 
El estilo de arquitectura basada en componentes enfoca el diseño de la aplicación 
informática como un conjunto de componentes interrelacionados y que poseen interfaces 
bien definidas. Estos componentes contienen reglas bien específicas y es comúnmente 
acompañado de uno o más elementos tecnológicos, a través de los cuales se implementa el 
soporte necesario para su operación. 
 
Características 
- Por medio de este estilo arquitectónico es posible el diseño de aplicaciones 
informáticas a partir del establecimiento de componentes individuales. 
- Se enfatiza sobre la descomposición del sistema en componentes las cuales 
contienen interfaces bien definidas que determinan métodos, eventos y 
propiedades. 
- Un componente en especial se diseña para una tarea específica y pueden 
reutilizarse. 
- El componente no debe almacenar información sino que éste la recibe y procesa. 
- Para ofrecer nuevas funcionalidades cada componente se extiende a través de la 
creación de nuevos componentes. 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 15 
 
 
- Como una medida de abstracción, no se revelan al usuario los detalles de los 
procesos que realiza cada componente sino que se presenta únicamente una 
interface sobre la cual realizar las operaciones necesarias a petición del usuario. 
- La independencia es un aspecto clave para que cada componente sea desplegado y 
aplicado sin que esta operación afecte el resto de la aplicación. 
 
Ventajas 
- Facilidad de sustitución de un componente por una nueva versión sin afectación del 
resto del sistema. 
- Conlleva a una reducción de costos al ser factible la utilización de componentes de 
terceros en el desarrollo y mantenimiento del software. 
- Al ser independientes del contexto donde se aplican, es posible explotar los 
procesos del componente para cualquier desarrollo.Cuándo usarlo 
- Existan ya componentes previos susceptibles de ser aplicables a un nuevo sistema. 
- Se ejecutarán procedimientos con muy pocos o inclusive, ningún dato de entrada. 
- Se desea combinar componentes que pueden haber sido desarrollados en distintos 
lenguajes de programación. 
 
Evitarlo cuando 
- El sistema a desarrollar es complejo y no se dispone de mucho tiempo para su 
construcción. 
- Los requerimientos de la aplicación no se encuentren definidos en su totalidad. 
- No se cuente con una alta disponibilidad de componentes con el estándar requerido 
para el desarrollo de la aplicación. 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 16 
 
 
 
2.2.2 Capas 
El estilo en Capas (N-Layer) “se basa en una distribución jerárquica de los roles y 
responsabilidades con el fin de proveer una división efectiva de los problemas a revolver” 
(De la Torre, C., Zorrilla, U., Calvarro, J. y Ramos, M. A. (2010). Guía de arquitectura N-Capas 
orientada al dominio con .NET 4.0, Página 23). Existe una secuencia ordenada donde cada 
capa ofrece a servicios de la capa posterior. El objetivo principal de la separación de los 
distintos componentes del software (la lógica del negocio, la vista del usuario, la capa de 
datos, entre muchas otras) es tener piezas identificables y unificadas sobre la base de la 
labor que desempeñarán dentro de la solución completa. Los sistemas computacionales 
organizados en capas (o arquitectura de software en capas) es uno de los hitos que 
mayormente aparece referido en la literatura especializada en arquitectura de software. 
 
Características 
- Es una organización jerárquica donde cada capa proporciona servicios a la capa 
inmediatamente superior y se sirve de los servicios de la capa inmediatamente 
inferior. 
- Se encapsula la implementación de los servicios de cada capa. 
- La mayoría de las interacciones suceden solamente entre capas adyacentes 
mediante la descomposición de los servicios que ofrecen. 
- La comunicación entre capas se realiza a través de la llamada a procedimiento con 
parámetros que son enviados entre cada capa. 
- Las distintas capas de la aplicación pueden residir en una sola máquina o se puede 
distribuir entre varios equipos para ofrecer un mayor rendimiento. 
- Permite mostrar una vista completa del modelo y las relaciones entre capas quedan 
claramente definidas, separando la funcionalidad de cada una. 
- Existe un bajo acoplamiento entre capas lo que provee un alto nivel de abstracción. 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 17 
 
 
 
- Los componentes deben tener un canal bien establecido de comunicación, en este 
caso los componentes del sistema son las capas. La manera en que se comunican las 
capas son los conectores, y la forma de comunicación está definido por los protocolos 
que determinan la interacción entre ellas. 
 
Ventajas 
- Provee un adecuado aislamiento lo que permite realizar modificaciones o 
actualizaciones en el interior de cada capa sin afectar el funcionamiento de resto de 
las capas o del sistema completo. 
- Las dependencias son claras y acotadas. 
- Al distribuir las capas en distintos niveles físicos se provee un mayor rendimiento ya 
que se mejorar la escalabilidad y la tolerancia a fallos. 
- La efectiva realización de pruebas sobre el sistema, al contar con una interfaz bien 
definida para cada una de las capas sobre la cual implementarlas permitiendo 
cambiar indistintamente entre cada implementación de una capa. 
- Permite y facilita aspectos como la reusabilidad y portabilidad. 
 
Cuándo usarlo 
- Es requerido un alto nivel de diseño debido a que la aplicación resulta ser muy 
compleja y es necesario que distintos equipos de desarrollo o soporte se concentren 
en aspectos separados de la funcionalidad. 
- La aplicación deba soportar y administrar varios clientes y dispositivos. 
- Comúnmente utilizado en: sistemas operativos, stacks de protocolos de red, 
aplicaciones empresariales con reglas de negocio complejas. 
- Se requiera la reutilización de capas previamente construidas o se cuente con 
aplicaciones que exponen la lógica de negocio con interfaces de servicios. 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 18 
 
 
 
Evitarlo cuando: 
- La aplicación a realizar es relativamente sencilla y sobre todo, las reglas de negocio 
cambiarán muy poco y no existen planes para el cambio de tecnologías de 
infraestructura durante la vida de la aplicación. 
- No se desea comprometer el performance de la aplicación. 
- No se requiera una separación física de los niveles, como en algunas aplicaciones 
web. 
 
 
2.2.3 Cliente/Servidor 
El estilo cliente/servidor establece una relación entre dos aplicaciones en las cuales una de 
ellas (cliente) inicia la comunicación y envía requerimientos a la otra aplicación (servidor) 
que los procesa y ejecuta y, si es necesario, envía la respuesta. 
 
Características 
- Los componentes son clientes y servidores. 
- Los servidores no conocen el número o identidades de los clientes sin embargo el 
cliente si conoce la identidad del servidor. 
- Divide al sistema en tres entidades: una aplicación cliente, una aplicación servidor y 
una red de conexión. 
- Los conectores están basados en protocolos de interacción entre redes. “Puede 
utilizar un amplio rango de protocolos y formatos de datos para comunicar la 
información” (De la Torre, C., Zorrilla, U., Calvarro, J. y Ramos, M. A. (2010). Guía de 
arquitectura N-Capas orientada al dominio con .NET 4.0, Página 19) 
- Dentro de los procesos que realiza el cliente podemos mencionar: 
• Envío de peticiones, procesamiento de la respuesta recibida. 
• Provee una interfaz gráfica para la comunicación directa con el usuario. 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 19 
 
 
 
- El servidor no realiza ningún tipo de petición al cliente, sino que solamente envía 
datos de respuesta a las solicitudes realizadas, previa autentificación y verificación 
del cliente o usuario. 
 
Ventajas 
- Seguridad, ya que los datos se almacenan en el servidor por lo cual es más fácil 
controlar el acceso a la información. 
- Acceso centralizado, ya que los datos deben encontrarse almacenados en un 
servidor lo que provee una mayor sencillez para su control y actualización. 
- Al distribuir los procesos, roles y funciones en distintos servidores permite su 
facilidad de mantenimiento y, como ya vimos, al existir independencia entre las 
capas, si falla un servidor en particular puede permitir que un cliente continúe 
trabajando sin que se vea afectado. 
 
Cuándo utilizar un estilo cliente/servidor 
- La aplicación debe correr en un servidor con soporte para múltiples clientes. 
- Se pretende el uso de la aplicación en un área local o en una LAN controlada, para 
cuestiones de seguridad y que permite que la funcionalidad relacionada con los 
procesos del negocio sean utilizados por la corporación. 
- Se planea centralizar el almacenamiento, respaldo y mantenimiento de la aplicación 
informática, que provees los beneficios antes mencionados. 
- La aplicación debe de soportar distintos tipos de clientes y dispositivos. 
- Aplicaciones empresariales. 
- El acceso del usuario final se limita a la captura de información y presentación de 
datos. 
Evitarlo cuando: 
- La centralización representa un alto riesgo de “falla en un solo punto”. 
- En ancho de banda de la red local es limitado. 
- Las máquinas de los clientes exceden las capacidades del servidor. 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 20 
 
 
- Condiciones de la red actual sin condiciones para el crecimiento futuro de los 
clientes. 
 
2.2.4 Orientado a Objetos 
Define el sistema comoun conjunto de objetos que interactúan entre sí. Se divide el sistema 
en estados y funciones los cuales son encapsulados en objetos que, como bien se indica en 
la programación orientada a objetos, deben ser instanciados antes que se asignen valores 
a sus propiedades y sus métodos sean invocados, todo mediante una interfaz gráfica. 
 
Características 
Las características de este estilo arquitectónico se relacionan con los conceptos y 
propiedades de la programación orientada a objetos. 
- El acceso a un determinado objeto se logra mediante operaciones, conocidas como 
métodos. 
- Describe cada uno de los objetos que contienen las propiedades y los métodos 
adecuados para procesar la información conforme a un requerimiento específico. 
- Se aplica la reutilización mediante las características propias de la programación 
orientada a objetos: encapsulación, polimorfismo y herencia. 
- Los objetos pueden llegar a componerse de otros objetos y ocultan las propiedades 
internas de otras clases o se exponen únicamente como interfaces. 
- Se aplica el concepto de herencia para adquirir propiedades de otros objetos 
utilizando su funcionalidad adaptándola en ocasiones para definir un nuevo 
comportamiento. 
- Los objetos ocultan los detalles internos de su implementación, la funcionalidad es 
expuesta únicamente a través de métodos, lo cual facilita la actualización de 
objetos. 
 
 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 21 
 
 
 
Ventajas 
- Al ser los objetos una representación del mundo real es más comprensible su 
implementación. 
- Abstracción: Ocultamiento de los detalles de implementación, que a su vez permite 
realizar las pruebas necesarias de una forma más sencilla. 
- Reusabilidad mediante el polimorfismo y la abstracción que permiten cambiar la 
implementación y a su vez la funcionalidad del objeto de una manera transparente 
al usuario. 
Cuándo usarlo 
- Se desea modelar luna aplicación informática mediante objetos reales y las acciones 
entre ellos. 
- Existan estructuras de datos complejas e interrelacionadas. 
- Correlación entre las entidades del mundo real y las entidades propias de la 
aplicación. 
- Se han diseñado previamente objetos que sirven al diseño y cumplen con aspectos 
operacionales. 
 
Evitarlo cuando 
- La aplicación es distribuida sobre una red heterogénea, el uso en aplicaciones 
distribuidas requiere acceso remoto a los objetos. 
- Es necesario implementar una fuerte dependencia entre los componentes del 
sistema. 
- Se requiere un alto rendimiento; existe una relativa ineficiencia en aplicaciones de 
este tipo. 
 
2.2.5 Tuberías y filtros 
El patrón arquitectónico de tuberías y filtros pertenece a las llamadas arquitecturas de flujo 
de datos. Se relaciona con redes de procesos y procesos secuenciales (procesos por lotes) y 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 22 
 
 
se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de 
entrada, los cuales entran al sistema y fluyen a través de los componentes. Un ejemplo de 
lo anterior sería: el cliente envía un requerimiento, el requerimiento es validado, un Web 
Service toma el objeto de la base de datos, se convierte en HTML, muestra la representación 
en pantalla. 
 
Características 
- La estructura del sistema se basa en transformaciones sucesivas a los datos 
establecidos de entrada. 
- Programas separados y ejecutados en orden. 
- Los datos son pasados como un lote de programa al siguiente. 
- Los datos ingresan al sistema y fluyen a través de los componentes hasta su destino 
final. 
- Los conectores constituyen distintas interfaces: desde humana hasta Web Services. 
- Su topología es lineal. 
- Se realiza la separación de programa conocidos también en este entorno como 
filtros. 
- Las “tuberías” enrutan los datos a través de los programas. 
 
Ventajas 
- Es fácil de implementar y permite ejecuciones independientes. 
- Obliga a que el proceso se lleve a través de una forma secuencial. 
- Es fácil aislar en una operación con un único resultado. 
- Los filtros se hacer fácilmente distribuibles. 
 
Cuándo usarlo: 
- Cuando se puede especificar la secuencia de un número conocido y finito de pasos. 
- Se requiere esperar la respuesta asincrónica de cada paso (ejecutar un programa a 
la vez hasta que éste termina). 
- Se busca que todos los componentes inferiores sean capaces de inspeccionar y 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 23 
 
 
actuar sobre los datos que vienen de componentes superiores (pero no viceversa). 
- Uno de los usos tipo de éste estilo arquitectónico es el procesamiento de 
transacciones en sistemas financieros. 
 
Evitarlo cuando: 
- Es necesaria la ejecución de una lógica de negocio compleja, que pueda ramificar la 
ejecución de una forma complicada. 
- Se maneja una lógica de negocios donde se involucren decisiones o repeticiones 
para el control del flujo. 
- Cuando eventualmente se llegue a requerir almacenamiento de tamaño no 
conocido no se recomienda su utilización. 
- Se requieran manejar situaciones interactivas de relación entre distintos actores. 
 
Cierre de la unidad 
En esta asignatura abordaste los estilos arquitectónicos, algunas recomendaciones de uso 
y aplicación dentro de la solución de un problema en un ámbito específico, lo que ayuda a 
que esta solución sea confiable y adherida a buenas prácticas de armado de arquitectura. 
La aplicación de los estilos arquitectónicos dará la flexibilidad y la facilidad de uso con la 
experiencia para hacer ágil la implementación de una arquitectura confiable al momento 
de diseñar la solución. El aprendizaje no debe quedarse en las explicaciones tan cortas y 
mejorables que se presentan en el desarrollo del tema o a lo largo de las unidades, es 
importante que se amplíes con la práctica y la consulta de fuentes bibliográficas externas 
para hacer un trabajo complementario. 
Es importante que identifiques un software de código libre y realices una descripción formal 
de arquitectura basándote en un lenguaje de definición de arquitectura, instálalo en tu 
computadora personal para que realices pruebas de descripción y veas la aplicación de los 
conceptos presentados. 
 
 
 
 
Unidad 2. Elementos de diseño de la arquitectura de software 
UNADM | DCEIT | DS | DDRS 24 
 
 
 
 
Fuentes de consulta 
 
• De la Torre, C., Zorrilla, U., Calvarro, J. y Ramos, M. A. (2010). Guía de arquitectura N-
Capas orientada al dominio con .NET 4.0. Madrid: Krasis Press. 
 
• Real Academia Española. (2012a). Patrón. En Diccionario de la lengua española. (22a 
ed.). [Versión electrónica]. http://lema.rae.es/drae/?val=patr%C3%B3n 
 
• Real Academia Española. (2012b). Modelo. En Diccionario de la lengua española. 
(22a ed.). [Versión electrónica]. http://lema.rae.es/drae/?val=modelo 
 
• Reynoso, C. y Kicillog, N. (2004). Estilos y patrones en la estrategia de arquitectura de 
Microsoft. Buenos Aires: Universidad de Buenos Aires. 
 
• Taylor, R.N., Medvidovic, N. y Dashofy, E. (2009). Software Architecture: 
Foundations, Theory and Practice. New Jersey: John Wiley & Sons. 
 
• Welicki, L. (2015). Patrones y Antipatrones: Una introducción - Parte I. 
https://docs.microsoft.com/es-es/previous- 
versions/bb972242(v=msdn.10)?redirectedfrom=MSDN - authorbrief 
http://lema.rae.es/drae/?val=patr%C3%B3n
http://lema.rae.es/drae/?val=modelo
https://docs.microsoft.com/es-es/previous-versions/bb972242(v%3Dmsdn.10)?redirectedfrom=MSDN&authorbrief
https://docs.microsoft.com/es-es/previous-versions/bb972242(v%3Dmsdn.10)?redirectedfrom=MSDN&authorbrief