Universidad Tecnológica de Panamá

Facultad de Ingeniería de Sistemas

Computacionales

Licenciatura en Ingeniería de Sistemas y Computación

Ingeniería de Software

Investigación #1

Profesor:

Maritza Morales

Integrantes:

Delgado, Luís 8-943-12

Yuliany, Guerrero 8-953-1809

Marín, Julio 20-53-4978

Tuñón, Valerie 8-950-5

Grupo:

1IL144

Fecha de entrega: 28 de junio de 2021

Semestre I

1
Contenido
1. Estilos Arquitectónicos....................................................................................................................... 5
1.1. Concepto........................................................................................................................................ 5
1.2. Utilidad de los estilos arquitectónicos....................................................................................5
1.3. Clasificación de estilos arquitectónicos.................................................................................6
1.3.1. Componentes independientes........................................................................................... 6
1.3.2. Flujo de datos........................................................................................................................ 8
1.3.3. Centrado en datos................................................................................................................ 8
1.3.4. Máquinas virtuales............................................................................................................... 9
1.3.5. Llamado y retorno.............................................................................................................. 10
2. Comparación entre los estilos vistos en esta investigación.....................................................11
3. Criterios para seleccionar un estilo arquitectónico....................................................................12
Conclusión.................................................................................................................................................... 14
Bibliografía................................................................................................................................................... 15

2
Introducción
En arquitectura de software los patrones (patterns) de diseño en una relación a veces
de complementariedad, otras de oposición, se encuentra la sistematización de los
llamados estilos arquitectónicos, tienen como destinatarios a distintas clases de
profesionales, o diferentes stakeholders, como se recomienda llamar a quienes
trabajan con estilos favorecen un tratamiento estructural que concierne a la teoría, la
investigación académica y la arquitectura en el nivel de abstracción más elevado,
mientras que quienes se ocupan de patrones se ocupan de cuestiones que están más
cerca del diseño, la práctica, la implementación, el proceso, el refinamiento, el código.

Los patrones coronan una práctica de diseño que se origina antes de que la
arquitectura de software se distinguiera como tema en perpetuo estado de formación y
proclamara su independencia de la ingeniería en general y el modelado en particular.
Los estilos, en cambio, expresan la arquitectura en el sentido más formal y teórico,
constituyendo un tópico esencial de lo que Goguen ha llamado el campo “seco”.

Desde los inicios de la arquitectura de software, se observó que en la práctica del

diseño y la implementación ciertas regularidades de configuración aparecían una y otra
vez como respuesta a similares demandas. El número de esas formas no parecía ser
muy grande. Muy pronto se las llamó estilos, por analogía con el uso del término en
arquitectura de edificios. Un estilo describe entonces una clase de arquitectura, o
piezas identificables de las arquitecturas empíricamente dadas. Esas piezas se
encuentran repetidamente en la práctica, trasuntando la existencia de decisiones 3
estructurales coherentes. Una vez que se han identificado los estilos, es lógico y
natural pensar en reutilizarlos en situaciones semejantes que se presenten en el futuro.

Igual que los patrones de arquitectura y diseño, todos los estilos tienen un nombre:
cliente-servidor, modelo-vista-controlador, tubería-filtros, arquitectura en capas… Como
conceptos, los estilos fueron formulados por primera vez cuando el escenario
tecnológico era sustancialmente distinto del que se manifiesta hoy en día. Es por eso
que en este estudio se analizarán las definiciones de los estilos arquitectónicos que se
han propuesto, así como su posición en el campo de las vistas de arquitectura, su lugar

3
en la metodología y su relación con los patrones, tomando en consideración las
innovaciones experimentadas por el campo de los estilos desde su formulación inicial
en 1992, coincidente con el instante que la IEEE identifica como el del nacimiento de la
arquitectura de software en sentido estricto.

Los estilos cuentan con el inherente interés descriptivo, taxonómico y heurístico.

También se ahondará en su relación con patrones y usos como una forma de vincular
la teoría con la práctica, aunque se sepa que sus mundos conceptuales difieren. Lo
importante aquí es que la teoría del arquitecto derive en la práctica de la
implementación de sistemas, que en ocasiones se presenta como dominada por un
pragmatismo propio de hackers o fundamentalistas de la orientación a objetos, como si
la empiría de la implementación no se coordinara con ningún orden de carácter teórico
(aparte de los objetos, por supuesto), o como si el conocimiento experto que se
pretende reutilizar en el bajo nivel no pudiera dar cuenta de sus propias razones
estructurales. El marco en el que se desenvuelve el presente estudio es el de la
estrategia de arquitectura de Microsoft, que en los últimos años ha hecho hincapié en
las arquitecturas basadas en servicios y en patrones de diseño. El propósito no es sólo
delimitar y tipificar un campo tan estrechamente relacionado con esta estrategia. Las
investigaciones académicas en arquitectura establecen una nomenclatura de formas
arquitectónicas que la documentación que ha comunicado la estrategia global de
Microsoft no tuvo oportunidad de poner en foco, dando por sentadas la mayor parte de
las cuestiones de naturaleza teórica y concentrándose en la práctica.

4
1. Estilos Arquitectónicos
Los estilos arquitectónicos han sido desarrollados debido a la creciente
utilización de sistemas informáticos en diversos proyectos empresariales e
institucionales, ya que al implementarlos se tiene una organización de la
estructura, funcionamiento e interacción entre las partes del software al que se
está queriendo realizar.

1.1. Concepto
Un estilo arquitectónico es una abstracción de tipos de elementos y
aspectos formales a partir de arquitecturas específicas. Se establece que
una arquitectura se define mediante la afirmación: Arquitectura del
Software está formada por Elementos, Forma y Razón. Cuenta con un
conjunto de reglas de diseño que identifica las clases de componentes y
conectores que se pueden utilizar para componer el sistema o subsistema
junto con las restricciones locales o globales de la forma en que la
composición se lleva a cabo. Los componentes del sistema están
encapsulados indicando la forma de empaquetado y la forma en que
interactúan con otros componentes, los procesos interactúan por medio
de protocolos de transferencia de mensajes o por flujo de datos, etc. Los
estilos arquitectónicos son entidades que ocurren en un nivel sumamente
abstracto y puramente arquitectónico.

1.2. Utilidad de los estilos arquitectónicos

Los estilos arquitectónicos se utilizan para sintetizar estructuras de
soluciones, abstraer estilos que a su vez encapsulan una enorme
variedad de configuraciones concretas, que definen los patrones posibles
de las aplicaciones, estas permiten evaluar las arquitecturas alternativas
con sus ventajas y desventajas conocidas ante diferentes conjuntos de
requerimientos no funcionales, es decir que restringen las decisiones de
diseño de un sistema a ese contexto y plantean como objetivo ciertas
cualidades para el sistema resultante. Establecen un vocabulario común,

5
 donde se dan nombres a los componentes y conectores, así como a los
elementos de datos Establecen un conjunto de reglas de configuración,
como la topología del sistema que definen una semántica para las reglas
de composición de los elementos y posibilitan el análisis de los sistemas
construidos sobre este estilo.

1.3. Clasificación de estilos arquitectónicos

Existe diversos estilos arquitectónicos debido a que se requieren
elementos, organización y procesos que se ajusten a un tipo de proyecto
de arquitectura de software específico. Podríamos llamarlas taxonomías
de primer orden, que describen los estilos individuales para examinar de
qué forma percepciones ligadas a dominios, mezclando referencias a las
mismas entidades a veces en términos de “arquitecturas”, otras invocando
“modelos de diseño”.

1.3.1. Componentes independientes

Un componente de software es un paquete, servicio web o un módulo
que encapsula un conjunto de funciones que se relacionan entre sí. El
estilo arquitectónico de componentes independiente se enfoca en
descomponer el sistema en componentes lógicos bien definidos para
que colaboren entre sí para resolver un problema. La ventaja de este
estilo es que los componentes pueden reemplazar un componente sin
afectar al resto, además se puede reutilizar componentes permitiendo
que se empleen en otras aplicaciones y sistemas.

6
 Ilustración 1 – Diagrama ejemplo de componentes diseñado en UML

 Sistemas basados en eventos

La arquitectura basada en eventos es un modelo y una arquitectura de

software que sirve para diseñar aplicaciones. En un sistema como este, la
captura, la comunicación, el procesamiento y la persistencia de los
eventos son la estructura central de la solución. Esto difiere del modelo
tradicional basado en solicitudes.

Muchos diseños de aplicaciones modernas se basan en eventos. Estas se

pueden crear con cualquier lenguaje de programación, ya que la
expresión "basado en eventos" se refiere a un enfoque de programación,
no a un lenguaje. La arquitectura basada en eventos permite un
acoplamiento mínimo, lo cual la convierte en una buena opción para las
arquitecturas de aplicaciones distribuidas y modernas.

Una arquitectura basada en eventos tiene un bajo nivel de acoplamiento

porque los productores de eventos no saben qué consumidores de
eventos están atentos a ellos, y el evento desconoce cuáles serán sus
consecuencias.

Esta arquitectura está compuesta por consumidores y productores de

eventos. El productor detecta los eventos y los representa como
mensajes. No conoce al consumidor del evento ni el resultado que
generará este último.

Una vez que se detecta un evento, este se transmite del productor a los
consumidores a través de canales de eventos, donde se procesa de
manera asíncrona con una plataforma para este fin. Ni bien se produce un
evento, se debe informar a los consumidores, quienes podrían procesarlo
o simplemente verse afectados por él.

La plataforma de procesamiento de eventos ejecutará la respuesta

adecuada para el evento y enviará la actividad en dirección downstream a
los consumidores correspondientes. Esta actividad downstream
corresponde al lugar en el que se verá el resultado del evento.

7
1.3.2. Flujo de datos
Estos estilos enfatizan en la reutilización y la modificabilidad,
implementan transformaciones de datos en pasos sucesivos de la
misma que serían las arquitecturas de tubería-filtros y las de proceso
secuencial en lote.

Tubería y filtros

Siempre se encuadra este estilo dentro de las llamadas arquitecturas

de flujo de datos. Es sin duda alguna el estilo que se definió más
temprano y el que puede identificarse topológica, procesual y
taxonómicamente con menor ambigüedad.

Una tubería (pipeline) es una popular arquitectura que conecta

componentes computacionales (filtros) a través de conectores (pipes),
de modo que las computaciones se ejecutan a la manera de un flujo.
Los datos se transportan a través de las tuberías entre los filtros,
transformando gradualmente las entradas en salidas.

Debido a su simplicidad y su facilidad para captar una funcionalidad,

cada vez que se trata de demostrar ideas sobre la formalización del
espacio de diseño arquitectónico, igual que el tipo de datos stack lo
fue en las especificaciones algebraicas o en los tipos de datos
abstractos. El sistema tubería-filtros se percibe como una serie de
transformaciones sobre sucesivas piezas de los datos de entrada. Los
datos entran al sistema y fluyen a través de los componentes. En el
estilo secuencial por lotes (batch sequential) los componentes son
programas independientes; el supuesto es que cada paso se ejecuta
hasta completarse antes que se inicie el paso siguiente.

Ilustración 2 - Diagrama ejemplo de flujo de datos

1.3.3. Centrado en datos

Este estilo enfatiza la integralidad de los datos, es la más apropiada para
sistemas que se fundan en acceso y actualización de datos en estructuras
de almacenamiento, los repositorios, las bases de datos, las arquitecturas
basadas en hipertextos y las arquitecturas de pizarra.

8
 En esta arquitectura hay dos componentes principales: una estructura de
datos que representa el estado actual y una colección de componentes
independientes que operan sobre él. En base a esta distinción se han
definidos dos subcategorías principales del estilo: Si los tipos de
transacciones en el flujo de entrada definen los procesos a ejecutar, el
repositorio puede ser una base de datos tradicional (implícitamente no
cliente-servidor). Si el estado actual de la estructura de datos dispara los
procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o
un tablero de control.

Ilustración 3 - Diagrama ejemplo de Máquina Virtual

1.3.4. Máquinas virtuales

La arquitectura de máquinas virtuales se ha llamado también intérpretes
basados en tablas. De hecho, todo intérprete involucra una máquina
virtual implementada en el software. Se puede decir que un intérprete
incluye un seudo-programa a interpretar y una máquina de interpretación.
El seudo-programa a su vez incluye el programa mismo y el análogo que
hace el intérprete de su estado de ejecución (o registro de activación). La
máquina de interpretación incluye tanto la definición del intérprete como el
estado actual de su ejecución.

 Una máquina de interpretación que lleva a cabo la tarea.

 Una memoria que contiene el seudo-código a interpretar.
 Una representación del estado de control de la máquina de
interpretación.
 Una representación del estado actual del programa que se simula.

Comprenden dos estilos:

9
  Intérpretes.
 Sistemas basados en reglas.

Ambas variedades abarcan, sin duda, un extenso espectro que va desde

los llamados lenguajes de alto nivel hasta los paradigmas declarativos no
secuenciales de programación, que encubren al usuario operaciones que
en última instancia se resuelven en instrucciones de máquinas afines al
paradigma secuencial imperativo de siempre.

1.3.5. Llamado y retorno

Son los estilos más generalizados en sistemas en gran escala enfatiza la
modificabilidad y la escalabilidad. Las técnicas más utilizadas en esta son
las arquitecturas de programa principal y sub-rutina, los sistemas basados
en llamadas a procedimientos remotos, los sistemas orientados a objeto y
los sistemas jerárquicos en capas.

Model-View-Controller (MVC).

Ilustración 4 - Diagrama ejemplo de llamado y retorno

El patrón conocido como Modelo-Vista-Controlador (MVC) separa el

modelado del dominio, la presentación y las acciones basadas en datos
ingresados por el usuario en tres clases diferentes.

 Modelo: El modelo administra el comportamiento y los datos del

dominio de aplicación, responde a requerimientos de información
sobre su estado y responde a instrucciones de cambiar el estado.
 Vista: Maneja la visualización de la información.
 Controlador: Interpreta las acciones del ratón y el teclado,
informando al modelo y/o a la vista para que cambien según
resulte apropiado.

10
2. Comparación entre los estilos vistos en esta investigación
Estilos Ventajas Desventajas
Arquitectónicos
Componentes  Reutilización de  Un componente
independientes componentes. comercial no tiene
posibilidad de acceso
 Permite integrar al código fuente para
nuevas tecnologías y modificar la
nuevos estándares funcionalidad del
para construir una componente.
organización propia.  No tienen
asociaciones y
ninguna
especificación en sus
interfaces, el
comportamiento de
los protocolos de
interacción con otros
componentes.
Flujo de datos  Reutilización  Secuencialidad
 Modificabilidad  Agregar un paso
 Fácil implementación suplementario podría
afectar la ejecución
de los procesos
 Es un estilo para
aplicarlo en casos
simples, debido a que
no da para ramificar
las ejecuciones.
Centrado en datos  Generan datos  Contiene grandes
complejos. dependencias entre
 Contiene técnicas de las estructuras y esto
reducción, genera
restauración y copia vulnerabilidades.
de seguridad.  El tratamiento de los
datos es costoso y
complejo.
Máquinas virtuales  Contiene técnicas de  Sobrecarga del
mantenimiento, sistema si se
recuperación y ejecutan diferentes
disponibilidad. máquinas de manera
simultánea.

11
 Llamado y retorno  Vistas múltiples de  Alta complejidad
los mismos datos de debido a los nuevos
manera simultánea. nivele añadido que
Existen páginas web dificulta la solución.
que usan el mismo  Las actualizaciones
modelo de objetos, tienden a ser
pero mostrado de costosas.
forma distinta.
 Adaptación a los
cambios de
requerimientos de
interfaz.

3. Criterios para seleccionar un estilo arquitectónico

La elección correcta de un estilo arquitectónico es importante porque éste guiará
todo el proceso posterior de desarrollo. En este sentido, los diseñadores deben
encontrar el estilo más apropiado de acuerdo con la especificación de los
requisitos concretos del sistema, incluyendo los funcionales, de escalabilidad,
disponibilidad, seguridad, mantenimiento y evolución.

Decidir cuál es la mejor opción va a depender de una serie de criterios de

calidad, muchos de los cuales suelen ser contradictorios entre sí (como ocurre,
por ejemplo, con el modularidad frente a la eficiencia). Por tanto, no sólo
habremos de identificar cuáles son los aspectos de calidad que se deben
considerar, sino también priorizarlos.

 La extensibilidad facilita la adición de nuevas características, aunque

ello puede hacer más complejo el diseño. En general, los sistemas
fácilmente extensibles presentarán mayor grado de abstracción.
Generalizar (por ejemplo, decidir qué tipo de extensiones pueden surgir,
los puntos de variabilidad, etc.) requiere invertir bastante tiempo en el
diseño. La distinción entre los requisitos opcionales y los deseables puede
ser también muy importante, ya que señala hacia dónde apuntará el
desarrollo del sistema.

12
 La modificabilidad tiene como objetivo primordial facilitar el cambio de
requisitos. Observad que ésta es distinta de la propiedad anterior, aunque
requiera técnicas similares.
 La simplicidad trata de hacer fácil de entender y de implementar el estilo.
En contrapartida, esta propiedad es difícil de compaginar con las dos
anteriores.
 La eficiencia derivará en aplicaciones de pequeño tamaño o alta
velocidad. Muchas veces la eficiencia va en contra de las propiedades
anteriores, ya que para aumentar la eficiencia nos podemos ver obligados
a saltarnos algunas de las normas de la arquitectura (como, por ejemplo,
acceder a capas inferiores en una arquitectura en capas).

13
Conclusión
La arquitectura del software nos proporciona una visión global del sistema a construir.
Los componentes del software incluyen módulos de programas y varias
representaciones de datos que son manipulados por el programa. La arquitectura
marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los
beneficios de las estructuras de sistema alternativas.

Los estilos y patrones son dos conceptos diferentes que tienen mucho en común. Por
lo que gracias a esta investigación hemos concluido que patrón es algo que se repite
de cierta forma una y otra vez, mientras que estilos son una forma de hacer
específicamente algo ya establecido.

Un modelo arquitectónico que posee requerimientos de calidad y usabilidad que deben

ser cumplidos. El correcto uso de los estilos arquitectónicos en el desarrollo de
software permite a las organizaciones obtener un producto con mayor rendimiento,
cumpliendo el alcance y los requisitos establecidos por los clientes, teniendo en cuenta
que el diseño arquitectónico es una pieza fundamental y el elemento entrante para que
los programadores generen un desarrollo funcional y a la medida, para finalmente
obtener el éxito del proyecto.

14
Bibliografía
1&1 IONOS España S.L.U. (23 de septiembre de 2020). IONOS Digitalguide. Obtenido
de Diagrama de componentes: modelado eficiente de sistemas con módulos de
software: https://www.ionos.es/digitalguide/paginas-web/desarrollo-
web/diagrama-de-componentes/

Blancarte, O. (2015). Obtenido de https://reactiveprogramming.io/blog/es/estilos-

arquitectonicos/p2p

BlogSpot. (26 de abril de 2015). Obtenido de

http://componentesindependiente.blogspot.com/2015/04/blog-post.html:
http://componentesindependiente.blogspot.com/2015/04/blog-post.html

Dutoit, B. B. (2002). Ingeniería de Software Orientado a Objetos. Prentice Hall.

Francisca Losavio, C. G.-D. (2012). Scielo. Obtenido de http://ve.scielo.org/scielo.php?

script=sci_arttext&pid=S0798-40652010000100008

IngSoftwareII-CUFM. (2012). Obtenido de

https://cufmingsoftware.wordpress.com/arquitectura-de-diseno/

Kendall, K. &. (2011). Análisis y Diseño de Sistemas. Pearson. 8va Edición.

Larman, C. (1999). Uml y patrones. Person Educación.

Martin, R. C. (2018). Clean Architecture: A Craftsman's Guide to Software Structure and

Design. Prentice Hall.

Pressman, R. (2002). Ingeniería de Software: Teoría y Práctica. Mc Graw-Hill V.

Red Hat. (s.f.). Red Hat. Obtenido de ¿Qué es la arquitectura basada en eventos?:
https://www.redhat.com/es/topics/integration/what-is-event-driven-architecture

Reynoso, C., & Kicillof , N. (2004). Estilos y Patrones en la Estrategia de Arquitectura

de Microsoft. BUENOS AIRE.

Rodríguez, A., & Silva, L. (2016). Arquitectura de software para el sistema de

visualización médica Vismedic. Revista Cubana de Informática Médica.

Salvador Sánchez, M. Á. (2012). Ingeniería del Software. Alfaomega, México.

Schach, S. (2005). Análisis y Diseño Orientado a Objetos con UML y el Proceso

Unificado. Mc Graw-Hill.

15
Sommerville, I. (2011). Ingenieria de Software. Pearson. 9a Edición.

16