meta anÁlisis de los estilos de arquitectura de … · detallados, esto con el fin de realizar un...

META ANÁLISIS DE LOS ESTILOS DE ARQUITECTURA DE SOFTWARE

ORIENTADOS A LA WEB

UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ D.C

2017

2

META ANÁLISIS DE LOS ESTILOS DE ARQUITECTURA DE SOFTWARE ORIENTADOS A LA WEB

Christian Romario Chacón Pinzón Juan Camilo Cárdenas Flórez

Trabajo de Grado para Optar al Título de

Ingeniero de Sistemas

DIRECTOR

DIEGO ALBERTO RINCÓN YÁÑEZ MCSc

INGENIERO DE SISTEMAS

UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ D.C

2017

NOTA DE ACEPTACIÓN

Aprobado por el comité de grado en cumplimiento de los requisitos exigidos por la Facultad de Ingeniería y la Universidad Católica de Colombia para optar al título de Ingenieros de Sistemas.

________________________________

Jurado

________________________________

Diego Alberto Rincón

Director

________________________________

Revisor Metodológico.

Fecha de Entrega: 29/05/2017

AGRADECIMIENTOS

Agradecemos a nuestros profesores e institución por el aprendizaje obtenido durante la carrera, que servirá no solo como conocimiento adquirido, sino como puesta en práctica en el ámbito laboral, formándonos como ingenieros íntegros y éticos. Agradecemos a nuestras familias por su esfuerzo y apoyo durante este proceso, y a Dios por permitir terminar una etapa más y abrir puertas para seguir creciendo profesionalmente y cumplir cada una de nuestras metas planteadas.

CONTENIDO

Pág.

1 INTRODUCCIÓN ........................................................................................................8

2 GENERALIDADES ................................................................................................... 10

2.1 Descripción del Problema. ................................................................................. 10 2.2 Formulación del Problema. ................................................................................ 11

3 OBJETIVOS ............................................................................................................. 12

3.1 Objetivo General. ............................................................................................... 12 3.2 Objetivos Específicos. ....................................................................................... 12

4 JUSTIFICACIÓN ...................................................................................................... 13

5 ALCANCES Y LIMITACIONES ................................................................................ 14

5.1 Alcances. ........................................................................................................... 14 5.2 Limitaciones....................................................................................................... 14

6 METODOLOGÍA ....................................................................................................... 15

6.1 Meta Análisis. .................................................................................................... 15

7 MARCO REFERENCIAL .......................................................................................... 17

7.1 Marco teórico. .................................................................................................... 17 7.2 Marco conceptual .............................................................................................. 19

7.2.1 Arquitectura de Software. ............................................................................... 19 7.2.2 Estilos de Arquitectura Software. ................................................................... 20 7.2.3 Taxonomía. .................................................................................................... 22

8 DEFINICIÓN DE LA TAXONOMÍA. .......................................................................... 23

8.1 Taxonomía de las arquitecturas de software. ..................................................... 23 8.1.1 Categoría basada en componentes: .............................................................. 23 8.1.2 Categoría basada en Mensajería ................................................................... 25 8.1.3 Categoría Basados en Solicitud y respuesta .................................................. 26 8.1.4 Categoría Basados en Memoria compartida .................................................. 29 8.1.5 Categoría Basados en Sistemas Adaptables ................................................. 30

8.2 Criterios de inclusión y exclusión de los estilos de arquitectura de software. ..... 32

9 APLICACIÓN METODOLOGÍA Y MODELO DE ANÁLISIS. .................................... 35

9.1 Evaluación de los estilos arquitectónicos de software. ....................................... 35 9.1.1 Modelo ATAM. ............................................................................................... 35 9.1.2 Fase de presentación: .................................................................................... 35 9.1.3 Fase de análisis e investigación: .................................................................... 36 9.1.4 Fase análisis de resultados ............................................................................ 42

10 TRABAJOS FUTUROS ............................................................................................ 50

11 CONCLUSIONES ..................................................................................................... 51

12 REFERENCIAS ........................................................................................................ 52

13 GLOSARIO ............................................................................................................... 55

LISTA DE TABLAS

Tabla 1 Categorías de los estilos de arquitectura de software ......................................... 32 Tabla 2 Selección de los estilos de arquitectura de software orientados a la Web. .......... 33 Tabla 3 Estilos de arquitectura de Software en análisis. .................................................. 34 Tabla 4 Estilo cliente-servidor. ......................................................................................... 36 Tabla 5 Estilo de arquitectura orientado a servicios ......................................................... 37 Tabla 6 Estilo peer to peer ............................................................................................... 38 Tabla 7 Estilo Rest ........................................................................................................... 38 Tabla 8 Atributos SOA (Brien & Merson, 2005) ................................................................ 39 Tabla 9 Atributos Cliente Servidor (Edgar & Luis, 1997) .................................................. 40 Tabla 10 Atributos Peer to Peer (Kicillof, 2004) ............................................................... 40 Tabla 11 Atributos REST (Roy Thomas Fielding, 2000) ................................................... 41 Tabla 12 Criterios de calidad por atributo(Mccall & Richards, 1977; Nuñez, 2004) .......... 42 Tabla 13 Cuantificación Disponibilidad ............................................................................ 44 Tabla 14 Cuantificación Confiabilidad .............................................................................. 44 Tabla 15 Cuantificación Interoperabilidad ........................................................................ 45 Tabla 16 Cuantificación seguridad ................................................................................... 46 Tabla 17 Cuantificación rendimiento ................................................................................ 47 Tabla 18 Cuantificación escalabilidad .............................................................................. 48 Tabla 19 Estilos destacados por atributo de calidad ........................................................ 48

TABLA DE FIGURAS

Figura 1 Meta-Análisis 16

Figura 2 Arquitectura filtros y tuberías donde se ve la interacción de cada componente 24

Figura 3 Arquitectura sistema de capas 24

Figura 4 Arquitectura dirigida por eventos 25

Figura 5 Estilo Publicación-Subscripción 25

Figura 6 Mensajes Asíncronos 26

Figura 7 Estilo cliente-servidor 27

Figura 8 Estilo SOA 27

Figura 9 Estilo broker 28

Figura 10 Estilo par a par 28

Figura 11 Estilo REST 29

Figura 12 Estilo blackboard 29

Figura 13 Estilo datos compartidos 30

Figura 14 Microkernel 30

Figura 15 Microservice 31

Meta Análisis de los Estilos de Arquitectura de Software Orientados a la Web

ABSTRACT

Currently there are a variety of styles of architecture of software available, for developers to

build software with quality in their companies. However the world of technology is moving

forward, and with the advent of the INTERNET, developers and architects are obliged to

create new styles that are oriented to the Web and in this way create new applications with

the highest standards of quality. This article will perform a meta-analysis of the Web-oriented

software architecture styles. Starting with a small description of a style of software

architecture, where a ranking of the most used styles will be reflected, continuing with the

selection of these by applying criteria of the selection. Once they are fully identified, you will

be a brief description of each one, applying the ATAM and MCCALL models for the analysis

of styles according to the quality attributes in a quantifiable way and finally generating the

ranking and the conclusions of the Study carried out during the research.

RESUMEN

En la actualidad hay una variedad de estilos de arquitectura de software disponibles, para

que los desarrolladores construyan software con calidad en sus empresas. Sin embargo, el

mundo de la tecnología está avanzando, y con la llegada del INTERNET, los desarrolladores

y arquitectos se ven en la obligación de crear nuevos estilos orientados a la Web y de esta

manera crear nuevas aplicaciones con los más altos estándares de calidad. En este artículo

se realizará un meta análisis de los estilos de arquitectura de software orientados a la Web.

A partir de una pequeña descripción de estilo de arquitectura de software, donde se reflejará

una clasificación de los estilos más utilizados, continuando con la selección de estos

mediante la aplicación de criterios propios de selección. Una vez estén totalmente

identificados, se hará una breve descripción de cada uno, aplicando los modelos de ATAM

y MCCALL para el análisis de los estilos de acuerdo a sus atributos de calidad de una manera

cuantificable y finalmente se generará el ranking y las conclusiones del estudio realizado

durante la investigación.


1 INTRODUCCIÓN

Desde los inicios de la arquitectura de software, se observó que en la práctica del diseño y la implementación ciertas disciplinas de configuración aparecían una y otra vez como respuesta a demandas. El número de esas formas no parecía ser muy grandes, muy pronto se les llamó estilos, por analogía con el uso del término en arquitectura de edificios.(Kicillof, 2004)

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, resumiendo la existencia de las estructurales de desarrollo;(Kicillof, 2004) lo que indica que a partir de la aplicación de un estilo de arquitectura se puede definir la estructura sobre la cual se encuentra desarrollado un software.

Hoy en día se cuenta con varias arquitecturas de referencia y estilos arquitectónicos que ayudan a identificar y diseñar la arquitectura de un sistema;(Mora, 2011) con el surgimiento de internet en los años 90’s, surgió un nuevo problema al diseñar software puesto que a medida que las aplicaciones crecían en complejidad y tamaño, es más difícil identificar la arquitectura del sistema puesto que su distribución, comportamiento y seguridad cambian respecto a aplicaciones locales(Mora, 2011), debido a esto se vio la necesidad de realizar un estudio para proponer nuevas arquitecturas aplicadas a la Web, definiendo así vistas arquitectónicas, componentes, conectores y estilos arquitectónicos, este último determinado como un conjunto de elementos (componentes y conectores) que pueden ser utilizados para describir una familia de sistemas y el conjunto de restricciones requeridas para poder combinarlos.(Mora, 2011)

El documento de Estilo arquitectónico para el sistema integrado de gestión Cedrux.(Arias, 2013), tiene como objetivo definir los elementos que componen la arquitectura de software del sistema, así como también su comportamiento arrojando resultados que contribuyan con el desarrollo de una herramienta de análisis. Lo anterior generará una propuesta con las definiciones actuales sobre la arquitectura de software de Cedrux y fundamentalmente con las brechas existentes que se tiene entre personas expertas en el tema como Arquitectos de software, analistas y desarrolladores(Arias, 2013). Sin embargo el documento indica solo una propuesta para desarrollar una herramienta que contribuya con el análisis arquitectónicos basada en estilos de software pero nunca enfocándose en la aplicación de estos y su integración a la Web.

De acuerdo con el documento Arquitectura de software para aplicaciones Web se aprecia que en la actualidad no evidencia claramente una descripción de arquitecturas de aplicaciones Web y los estilos arquitectónicos no brindan una especificación de la arquitectura de estas aplicaciones, dando como resultado arquitecturas deficientes que no cumplen con los requerimientos del software.(Mora, 2011)


De acuerdo a lo expuesto anteriormente se ve la necesidad de generar un estudio apoyado en una metodología de meta análisis que permita formular, definir, codificar, calcular, interpretar y generar resultados que den a conocer el estado actual de los estilos arquitectónicos orientados a la Web llevándolos a una documentación que sirva de guía para la aplicación de buenas prácticas para el desarrollo de software; la metodología se apoyara en los modelos ATAM y este a su vez en el modelo de Mccall.

Inicialmente se realizará un estudio de los diferentes estilos de arquitectura agrupados por categorías, esta representación es fuente para generar una taxonomía a la cual se le aplicaran criterios de inclusión y exclusión con el fin de especificar cuáles son los estilos de arquitectura orientados a la Web, esto cumpliría con la primera fase del ATAM y es origen de la evaluación, la cual en su segunda fase realiza la descripción de los atributos de calidad para cada estilo.

A continuación se identifican criterios para cada uno de los atributos de calidad anteriormente detallados, esto con el fin de realizar un análisis cuantitativo de acuerdo modelo Mccall; para luego crear un ranking con los estilos que obtuvieron el mayor puntaje de cumplimiento, generando un análisis de resultado y conclusiones finales del análisis elaborado.


2 GENERALIDADES

2.1 Descripción del Problema.

Hoy en día las investigaciones, definiciones y análisis de los estilos arquitectónicos se encuentran moldeados en diferentes documentos los cuales describen de cierta forma el concepto de estilos arquitectónicos como, por ejemplo:

En el documento Catálogo Incompleto de Estilos Arquitectónicos (Cristi, 2006) el autor describe alrededor de seis estilos arquitectónicos (Invocación Implícita, Tubos y Filtros, Sistemas Estratificados, Control de Procesos, Blackboard Systems y Cliente/Servidor de Tres Capas) mediante una serie de etapas en donde describen sus propósitos, aplicabilidad, componentes, conectores, patrones estructurales, modelo computacional subyacente, invariantes esenciales, metodología de diseño, análisis, documentación, especificaciones y deformaciones comunes; sin embargo este documento solo se limita a ciertos estilos que para el autor son relevantes.(Cristi, 2006)

Verificando el documento Estilos y Patrones en la Estrategia de Arquitectura de Microsoft el cual propone inicialmente el estudio de diferentes estilos arquitectónicos pero en el desarrollo de su investigación se limita a cierto estilos los cuales son divididos en familias tales como estilos de flujo de datos, estilos centrados en datos, estilos de llamada y retorno, estilos de código móvil, estilos heterogéneos y estilos peer to peer, se puede evidenciar que el autor al igual que el anterior solo realiza el estudio de aquellos estilos que él prefiere y adicionalmente solo aquellos relacionados a la arquitectura de Microsoft.(Kicillof, 2004)

Siguiendo la tesis Arquitectura de software para aplicaciones Web se aprecia que en la actualidad no existe una representación formal para la descripción de arquitecturas de aplicaciones Web y los estilos arquitectónicos no brindan una especificación de la arquitectura de estas aplicaciones, dando como resultado arquitecturas deficientes que no cumplen con los requerimientos de la aplicación; dada la problemática la arquitectura Web propone la descripción formal de todas las partes que integran la arquitectura de estos sistemas, lo que permitirá obtener arquitecturas estructuradas y detalladas que cumplan con los requerimientos del sistema de mejor forma.(Mora, 2011)

Por tanto, se evidencia que no se expone claramente una definición de los estilos arquitectónicos orientados a la Web, ni tampoco cuáles de ellos son los más usados en la actualidad y su implementación, es así que se hace necesario tener un documento en el cual se encuentren contenidos estos temas y ayude a orientar en el desarrollo arquitectónico de software orientado a la Web.


2.2 Formulación del Problema.

¿Cuál es el estado actual de los estilos de arquitectura de software orientados a la Web, cuáles de ellos tienen un mejor desempeño y como su implementación puede ayudar a obtener un mejor producto de desarrollo a los arquitectos y desarrolladores?


3 OBJETIVOS

3.1 Objetivo General.

Desarrollar una meta análisis de estilos de arquitectura orientados a la Web.

3.2 Objetivos Específicos.

Definir la taxonomía de estilos de arquitectura orientados a la Web y sus componentes.

Definir un análisis cuantitativo de los estilos de arquitectura orientados a la Web.

Desarrollar una evaluación sobre el análisis cuantitativo.

Realizar la publicación del artículo con los resultados del análisis cuantitativo.


4 JUSTIFICACIÓN

En la actualidad no existe una definición clara y estructurada, así como suficiente información de beneficios y usos de los estilos arquitectónicos que estén orientados a la Web y es importante puesto que son un apoyo para los arquitectos y desarrolladores a la hora de implementar. Es necesario realizar una investigación, un análisis y llevarlo a una documentación con los contenidos adecuados que sirva de guía y ayude a orientar en el desarrollo de software basado en la Web, dando pasó a que otras personas se motiven a investigar y enfatizar en estos estilos arquitectónicos.


5 ALCANCES Y LIMITACIONES

5.1 Alcances.

El presente trabajo de investigación desarrollará un análisis cuantitativo entre los estilos de arquitectura de software.

La investigación sólo abarcará los estilos de arquitectura de software orientados a la Web.

Realizar un artículo acerca de los resultados obtenidos y evaluados durante la investigación.

5.2 Limitaciones.

El periodo de tiempo de recolección de la información necesaria para la investigación es de seis meses a partir de julio de 2016.

El acceso a parte de la documentación acerca del tema es de pago y de suscripción a páginas de investigación.


6 METODOLOGÍA

Se usará la siguiente metodología para alcanzar los objetivos planteados ya que esta metodología nos permite desarrollar el estado del arte del tema de investigación propuesto, con una organización contundente y clara que tenga lo necesario para minimizar los riesgos y garantizar la calidad del documento final que se desarrollará y que se publicará en revistas de ciencia e investigación.

6.1 Meta Análisis.

Es una metodología que tiene como propósito integrar de forma objetiva y sistemática los resultados de los estudios empíricos sobre un determinado problema de investigación, con objeto de determinar el estado del arte en ese campo de estudio. Para alcanzar este objetivo, la realización del meta-análisis requiere las siguientes etapas.(Sánchez, 2013b)

1. Formulación del problema. Se debe formular de forma clara la pregunta que se pretende responder, así como definir los conceptos implicados en la misma. De la formulación de la pregunta surgen a continuación los objetivos que se pretenden alcanzar con el meta análisis.(Sánchez, 2013b)

2. Definición de los criterios de inclusión y búsqueda de los estudios. Este paso consiste en localizar los estudios empíricos que hayan abordado la pregunta objeto de investigación. Esta fase pasa necesariamente por la definición de los criterios de inclusión y exclusión de los estudios. Estos criterios dependen del objetivo de la meta análisis.(Sánchez-meca, 2010b) Partiendo de los criterios de inclusión y exclusión de los estudios, se procede a realizar una búsqueda bibliográfica lo más amplia posible para identificar los estudios que pueden cumplir con los criterios de selección.

3. Codificación de las características de los estudios que puedan moderar los resultados. En este paso se elabora un manual de codificación en el que se hagan explícitos los criterios mediante los cuales se van a codificar las características de los estudios. La razón de examinar no es otra que comprobar qué características de los estudios pueden estar moderando o afectando los resultados.(Sánchez-meca, 2010b)


4. Cálculo del tamaño del efecto. En este paso se hace preciso calcular un índice estadístico que sea capaz de reflejar la magnitud del efecto obtenido en cada estudio. Ese índice estadístico tiene que ser tal que pueda calcularse de forma homogénea en todos los estudios, de forma que sea capaz de poner en la misma métrica los resultados de los estudios.(Sánchez-meca, 2010b)

5. Técnicas de análisis estadístico e interpretación. En este paso toda la información recopilada en los dos pasos anteriores se informará creando una base de datos en la que las filas son los estudios y las columnas son las variables potencialmente moderadoras de los resultados de los estudios, así como el tamaño del efecto obtenido en cada estudio. Un paso previo en el análisis estadístico consiste en describir las características de los estudios que se han codificado, con objeto de obtener una imagen prototípica de los estudios. Una vez hecho esto, el análisis estadístico típico de un meta análisis pasa por tres fases: (1) cálculo del tamaño del efecto medio con su intervalo de confianza y valoración de su significación estadística; (2) análisis de la heterogeneidad de los tamaños del efecto, y (3) si los tamaños del efecto son heterogéneos, realizar búsqueda de variables moderadoras de tal variabilidad.(Sánchez-meca, 2010b)

6. Publicación del meta-análisis. La última etapa en la realización del meta análisis, como de cualquier otra investigación, es su publicación. Al tratarse de una investigación empírica, las secciones que debe incluir el informe escrito del meta análisis son las típicas de un estudio empírico: introducción, método, resultados y conclusiones.

Figura 1 Meta-Análisis (Juan C . Cardenas F; Christian R. Chacon P, 2017)

FASE 1: FORMULACION DEL

PROBLEMA.

Formulacion de la pregunta de

investigación.

Definir los objetivos del proyecto de investigación.

Definir los alcances y los límites del proyecto de

investigación.

FASE 2: DEFINICIÓN DE LOS CRITERIOS DE

INCLUSIÓN Y BÚSQUEDA DE LOS

ESTUDIOS.

Definir los criterios de inclusión y exclusión

de los estudios.

Realizar la búsqueda bibliográfica que

cumplan los criterios de selección.

FASE 3: CODIFICACIÓN DE

LAS CARACTERÍSTICAS DE

LOS ESTUDIOS.

Comprobación de las características de los

estudios.

Realizar un Manual de Codificación.

FASE 4: CÁLCULO DEL TAMAÑO DEL

EFECTO.

Caclular un índice estadístico

homogéneo que refleje la magnitud del efecto obtenido

en cada estudio.

FASE 5: TÉCNICAS DE ANÁLISIS

ESTADÍSTICO E INTERPRETACIÓN.

Crear una base de datos en base a la

información recopilada en los dos

pasos anteriores.

Describir las características de los estudios que se han

codificado.

Cálculo del tamaño del efecto medio con

su intervalo de confianza y

valoración de su significación estadística.

Análisis de la heterogeneidad de

los tamaños del efecto.

Realizar búsqueda de variables moderadora

si los tamaños del efecos son

heterogéneos.

FASE 6: PUBLICACIÓN DEL META ANÁLISIS.

Revisión y corrección del artículo que se

publicará.

Publicación del artículo de

investigación.


7 MARCO REFERENCIAL

7.1 Marco teórico.

En 1968, Edsger Dijkstra realiza la publicación de un documento sobre diseño de un sistema multiprofesional llamado “The”. (Albin, 2003) En este documento se describe el diseño de un sistema de software usando capas jerárquicas, realizado con el fin de reducir complejidades de un software, y fue el primer vistazo de la arquitectura de software. En la década de 1970 se elaboraron modelos de diseño y desarrollo de software estructurados que contaban con enfoques evolutivos, lo que permitió realizar una búsqueda profunda de diseño de software para abordar los problemas de desarrollo para sistemas de software complejos, encontrando así que las actividades de diseño y desarrollo se complementan entre sí, pero se trabajan por separado, ya que requieren sus propias herramientas, técnicas, lenguajes de modelado.(Albin, 2003)

Para el año de 1972 David Parnas publicó un documento que analiza como un adecuado diseño de sistemas podría mejorar la flexibilidad de un software, generando reducción de tiempos en el desarrollo. Para la década de 1980, la investigación en ingeniería de software realizo cambios enfocándose en la integración de diseños y procesos de diseño para complementar de una manera más amplia el desarrollo de un sistema. A medida que se realizaban investigaciones más detalladas se generaban nuevos paradigmas, para el año 1990, el término “Arquitectura de software” comenzó a tener importancia, generando inquietud de conocer como utilizando estructuras para la implementación de un software podría mejorar en aspectos de rendimiento, escabilidad, entre otras.(Albin, 2003)

Con la llegada de Internet que se convirtió en la nueva plataforma informática y con los experimentos realizados en los paradigmas de software encontrados, se obtuvieron integraciones de métodos generando diseños más estructurados que incluían técnicas de diagramas.

Estas técnicas ayudaron a los programadores a realizar un desarrollo más estructurado, ya que los datos eran útiles y funcionales, y los diseñadores reconocían la utilidad de manejar métodos y técnicas en la ejecución del proyecto. Permitiendo así una mejor organización en la implementación de un sistema.(Garlan & Shaw, 1994a)

Según la definición de IEEE, el diseño es Tanto "el proceso de definición de la arquitectura, los componentes, Interfaces y otras características de un sistema o componente "Y "el resultado de ese proceso". El diseño arquitectónico es el punto en el que requerimientos de procesos permiten diseñar e ilustrar de una manera más eficiente que no genere retrasos a la hora de realizar la programación del software.(Committee, 2004) Cuenta con fases de guía, entre ellas la primera contiene las generalidades de diseño de software, que definen el alcance del diseño de acuerdo a los requisitos solicitados; la segunda fase cuenta con análisis claves, incluye validación de eventos, distribución de componentes, validación de errores y excepciones, entre otros. La tercera fase es la definición de estructura y arquitectura de software, donde se validan los estilos arquitectónicos, patrones de diseño y


familias de programas y marcos. Esto conlleva a ver el diseño arquitectónico como una pieza en la arquitectura de software.(Committee, 2004)

¿Y qué es la Arquitectura de software? Es la estructura del sistema que contiene elementos de software, tales como, propiedades visibles externamente y las relaciones entre ellos.(Cristi, 2014) Entre otras definiciones se tiente: 4+1view-architecture “Una arquitectura es el conjunto de decisiones significativas sobre la organización de un sistema de software, la selección de los elementos estructurales y sus interfaces que componen el sistema, junto con su comportamiento tal como se especifica en las colaboraciones entre esos elementos, la composición de estos elementos estructurales y comportamentales en subsistemas progresivamente más grandes, y el estilo arquitectónico que guía dicha organización”(Kruchten, 1995)

“La arquitectura de software de un programa o sistema de cómputo es la estructura o estructuras de un sistema, que comprenden elementos de software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos. La arquitectura se refiere a la parte pública de las interfaces; los detalles privados de los elementos – detalles que tienen que ver sólo con la implementación interna – no son arquitectónicos.” (Committee, 2004)

“La organización fundamental de un sistema, encarnada en sus componentes, sus relaciones entre sí y con el entorno, y los principios que gobiernan su diseño y evolución.”(Ing & Rienzi, 2009)

Dentro de la arquitectura de software se encuentra la extracción arquitectónica, que se define como la colección de componentes de nivel arquitectónico, las restricciones y justificación de un sistema. Esta extracción debe incluir todas las vistas del sistema, tanto vista de usuario, desarrollador, mantenimiento y pruebas y cada una puede tener una sub-vista, para así generar una visión estructural funcional del sistema.(White, 1995)

El proceso de arquitectura se caracteriza por tres actividades generales: Extracción, Generalización, Reutilización. Que permiten optimizar modelos de ciclos de vida existentes.

La arquitectura de software contiene estilos arquitectónicos, definidos como abstracciones de los patrones de diseño. Se caracterizan por relacionarse entre sí para compartir propiedades estructurales y funcionales.(Ing & Rienzi, 2009)

En el presente trabajo se analizará los estilos de arquitectura de software, su estado actual y cómo se están implementando en el desarrollo de aplicaciones. En ese sentido, es preciso aclarar los conceptos que se van a contemplar durante el desarrollo del proyecto de investigación.

Para abordar los estilos de arquitectura de software se debe conocer el concepto de arquitectura de software. 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.


Tomando como base este concepto se entenderá entonces que los estilos de arquitectura de software son la forma como los componentes, interfaces y medios de comunicación están construidos y definidos siguiendo un patrón común (Garlan & Shaw, 1994), de esta manera la arquitectura de software puede implementar un mismo patrón y compartir sus características y por esta razón los estilos de arquitectura tienen un nivel de abstracción mayor.

Está investigación se centra en el estudio, análisis y crítica de los estilos de arquitectura de software orientados a la Web utilizados por los arquitectos de software en la actualidad, para así poder realizar una evaluación de los resultados de los análisis hechos durante la investigación.

7.2 Marco conceptual

7.2.1 Arquitectura de Software.

Se puede definir la 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). Determinando cómo asignar componentes para formar un sistema, como deben interactuar los elementos que lo conforman e identificando los protocolos de interfaz necesarios para la conexión y comunicación.(Roy T Fielding & Taylor, 1993)

Dentro de las ventajas de la arquitectura de software, se encuentra que: simplifica la capacidad de comprender sistemas complejos planteando limitaciones en el diseño, reutiliza componentes en múltiples niveles, separa elementos, lo que permite mayor facilidad en el cambio y mantenimiento del desarrollo, aplica utilización de patrones.(Garlan & Garlan, 2000). El uso de patrones arquitectónicos de software puede ayudar en gran medida, a desarrollar y resolver sistemas complejos, permitiendo identificar que tan difícil es implementarlo y actualizarlo.(Dong & Chen, 2005)

Estos patrones son la clave para la búsqueda de soluciones a problemas en el desarrollo del software y en el diseño de interfaces. Los patrones de diseño deben ser claros, porque estiman el tiempo y costo de la implementación de un software, así como identifican de primera vista errores que permitirán disminuir los cambios una vez se desarrolle y pruebe el software. Dentro de las características de los patrones de diseño se contempla: reutilización de diseños de otro software, formalización en el vocabulario común entre diseñadores, estandarización en el modo de realizar el diseño y guía para próximos desarrollos.(Mora, 2011)

Es importante plantear las limitaciones y contar con una documentación clara y completa en el diseño arquitectónico, las decisiones tomadas no pueden carecer de representación a la hora de documentar, porque pueden ser interpretadas de otra forma, afectando la implementación cuando el recurso que lo va a utilizar no es una persona involucrada en el diseño inicial del sistema. Si se interpreta de una manera diferente, puede generar altos costos en los cambios de funcionalidades o módulos del software.(Bosch, 2004)


Cuenta con tres puntos de vista, los de procesamiento, datos y conexiones, los tres puntos de vista son necesarios y útiles a nivel arquitectónico, según el punto de vista se determina el resultado. Si el énfasis resultante está en el flujo de datos se realiza a través de los elementos de procesamiento y en ciertos casos con aspectos de las conexiones entre los elementos de procesamiento y datos. Por el contrario, si es una vista de datos de una arquitectura, el resultado está en el flujo de procesamiento, dándole más importancia a la vista de proceso que a los elementos de conexión.(Perry, Laboratories, Hill, & Wolf, 1992)

7.2.2 Estilos de Arquitectura Software.

Un estilo de arquitectura se define como como una familia de sistemas con patrones comunes de una organización estructurada.(Garlan & Shaw, 1994a) Los estilos arquitectónicos determinan las clases de arquitectura de software teniendo en cuenta los tipos de elementos de la arquitectura y su topología, y los patrones de datos y control entre los elementos.(Rapanotti et al., 2004)

Los estilos arquitectónicos, definen importantes decisiones sobre los elementos arquitectónicos y su relación. Estos estilos se pueden usar para restringir la arquitectura como para coordinar a los arquitectos que interactúan en su desarrollo.(Perry et al., 1992). Son útiles durante el análisis y diseño de un sistema, porque el arquitecto puede determinar el estilo que más se acople en la construcción del software y el que cumpla con los objetivos deseados.(Klein et al., 2008)

Están compuesto por: Un conjunto de tipos de elementos (como ejemplo, un repositorio de datos), una topología, un conjunto de restricciones semánticas y un conjunto de mecanismos de interacción que determinan cómo los elementos coordinan a través de la topología establecida.(Bash, 2015)

El uso de estilos puede mejorar algunos atributos de calidad definidos para un sistema, pero disminuir otros, un ejemplo es el uso de un estilo en capas, aumenta la flexibilidad del software pero generalmente disminuye el rendimiento, por eso es importante implementar y adecuar un estilo que se adapte con las necesidades del sistema.(Science, 1999)

Los estilos arquitectónicos, definen importantes decisiones sobre los elementos arquitectónicos y su relación. Estos estilos se pueden usar para restringir la arquitectura como para coordinar a los arquitectos que interactúan en su desarrollo.(Perry et al., 1992)

Seguidamente se describirán algunos estilos de arquitectura de software:

7.2.2.1 Tuberías y Filtros.

En este estilo de arquitectura cada componente del sistema maneja de manera independiente un flujo de entrada de datos y un flujo de salida de datos el cual es de forma incremental. La forma como funciona este estilo de arquitectura es el siguiente:


Los datos ingresan por las tuberías y llegan a los filtros (componentes) los cuales se encargan de manipular y realizar el proceso de transformación de los datos que ingresan y les da salida por otras tuberías las cuales están conectadas con otros filtros los cuales irán realizando la misma operación hasta que se finalice el flujo de entrada de datos.(Garlan & Shaw, 1994a). Los ejemplos más comunes de este estilo de arquitectura son el Shell de Unix, sistemas distribuidos y compiladores (Garlan & Shaw, 1994a).

Una topología importante en la arquitectura basada en este estilo, es la Tubería lineal en la que cada filtro tiene precisamente un tubo de entrada (su fuente) y un tubo de salida (su sumidero). Permitiendo transformar algo de entrada en alguna salida de un formato particular, aplicando ciertas reglas en el proceso.(Rapanotti et al., 2004)

7.2.2.2 Abstractos de Datos y POO.

En estos estilos de arquitecturas los componentes son tomados como objetos abstractos cuyos conectores son llamados invocaciones de métodos. Su función es ocultar las características de los objetos y obviarlas puesto que necesariamente se debe conocer que es lo que hace el objeto o que funciones tiene (Garlan & Shaw, 1994a).

7.2.2.3 Sistemas 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).

7.2.2.4 Cliente – Servidor.

Este estilo de arquitectura se basa en que un proceso provee servicios (Servidor) por medio de una o varias peticiones de otros procesos (Clientes), los cuales consumen dichos servicios y son los encargados de enviar las peticiones al servidor. Un ejemplo son los sitios Web. La acción de visitar un sitio Web requiere una arquitectura cliente-servidor, ya que el servidor Web sirve las páginas Web al navegador (al cliente) (Garlan & Shaw, 1994a).

Este estilo siempre se debe ejecutar en una máquina que hará la tarea de cliente y por lo menos un servidor que se ejecutara en una segunda máquina. El cliente y el servidor son procesos computacionales que se ejecutan desde la memoria de sus respectivas máquinas, estos son procesos independientes y pueden ser ejecutados en cualquier plataforma, haciendo uso de sistemas de gestión cliente-servidor proporcionan una nueva capacidad para crear elementos habilitados, como por ejemplo un sistema informático que ejecuta un sistema conectado a la red o un usuario pueda editar un gestor.(View, Lu, Carlton, & Carlos, 2003)


7.2.2.5 Arquitectura Orientada a Servicios (SOA).

Este estilo de arquitectura se basa en la comunicación de varios sistemas de información independientes desarrollados en diferentes lenguajes, desplegados en diferentes servidores de aplicaciones tales como IIS, tomcat, glassfish, JBoss, WebLogic, ejecutados en diferentes Sistemas Operativos como lo son Windows, Mac, Linux, y con motores de base de datos diferentes como SQL Server, MySql, Oracle, Postgress, los cuales se pueden comunicar por la red para ofrecer sus funcionalidades por medio de publicación de servicios. Esta arquitectura de software se puede realizar mediante servicios Web. Un ejemplo claro de Arquitectura Orientada a Servicios son los servicios REST (J & Sc, 2009).

Esta arquitectura comprende múltiples funciones, dentro de su propio nombre y espacio de

direcciones, interactuando remotamente a través de una red utilizando algún protocolo (No

requiere que los protocolos estén libres de contexto). En la mayoría de los casos, SOA de

basa en aplicaciones distribuidas, estas se distinguen de otros sistemas distribuidos, porque

los servicios pueden ser implementados en diferentes idiomas y pueden ejecutarse en varias

máquinas, cada petición realizada se aloja en espacios de direcciones separadas en

máquinas separadas.(Taylor, 2009)

7.2.2.6 Peer to Peer

Conjunto de recursos distribuidos heterogéneos que se conectan entre sí por medio de una

red. Una de sus principales características es, que puede funcionar al mismo tiempo como

cliente así como servidor, que a diferencia de la arquitectura Cliente – Servidor, esta puede

actuar como un servidor o como un cliente, pero no puede operar ambas

capacidades.(Schollmeier, Networks, & Universität, 2002)

Conjunto de recursos distribuidos heterogéneos que se conectan entre sí por medio de una

red. Una de sus principales características es, que puede funcionar al mismo tiempo como

cliente así como servidor, que a diferencia de la arquitectura Cliente – Servidor, esta puede

actuar como un servidor o como un cliente, pero no puede operar ambas

capacidades.(Schollmeier, Networks, & Universität, 2002). Este estilo contiene sistemas

distribuidos en donde el software que corre en cada nodo proporciona funciones

equivalentes y no se tiene control centralizado.(Fernando et al., 2006)

7.2.3 Taxonomía.

La taxonomía es un método de clasificación de acuerdo a las características, similitudes o diferencias, en las especies biológicas (Española, 2016).


8 DEFINICIÓN DE LA TAXONOMÍA.

En esta sección se define la taxonomía de los estilos de arquitectura de software, realizando una descripción detallada de sus diferencias, semejanzas y los criterios que se tienen en cuenta para la clasificación de los estilos de arquitectura de software orientados a la Web.

8.1 Taxonomía de las arquitecturas de software.

Se realiza la clasificación de los estilos de arquitectura de software teniendo en cuenta la categoría la cual pertenecen sus características y funcionalidades comunes, de esta manera se realiza una completa categorización la cual se describirá a continuación:

8.1.1 Categoría basada en componentes:

En esta categoría se encuentran los estilos de arquitectura básicos y los cuales sirven como componentes de otros estilos de arquitectura más robustos y complejos tales como SOA, REST, Cliente-Servidor, etc. A continuación, se definirán los estilos de arquitecturas que pertenecen a esta categoría:

8.1.1.1 Estilo Basado en Componentes.

En el estilo basado en componentes se dividen los sistemas en componentes físicos o lógicos con interfaces bien definidas para que de esta manera cada componente pueda definir una funcionalidad o una información específica. Aquí un componente podría ser una pieza de información de datos, recursos o un servicio Web (Sharma, Kumar, & Agarwal, 2015).

Figura 2 Arquitectura basada en componentes (Kumar, 2014; Sharma et al., 2015).


8.1.1.2 Estilo tubería y filtros.

En este estilo de arquitectura de software, en donde los filtros se refieren a un proceso y las tuberías se utilizan para conectar los filtros para que de esta manera un filtro actúe como entrada del siguiente filtro conectado entre sí por una tubería. Este estilo de arquitectura de software es unidireccional y es comúnmente usada en el sistema operativo UNIX (Kumar, 2014; Sharma et al., 2015).

Figura 3 Arquitectura filtros y tuberías donde se ve la interacción de cada componente (Kumar, 2014; Sharma et al., 2015).

8.1.1.3 Estilo sistema de capas.

En este estilo de arquitectura es una organización jerárquica en la que cada capa proporciona servicios a la capa superior y se sirve de las prestaciones que le brinda la capa inmediatamente inferior. En este estilo de arquitectura los conectores se definen mediante protocolos los cuales determinan las formas de interacción (Garlan & Shaw, 1994a; Sharma et al., 2015). En la figura 4 se muestran los principales componentes de esta arquitectura.

Figura 4 Arquitectura sistema de capas (Garlan & Shaw, 1994; Kumar, 2014; Sharma et al., 2015).


8.1.2 Categoría basada en Mensajería

En esta categoría se encuentran los estilos de arquitectura que se basan en mensajería y que se encargan del tráfico de mensajes ya sea petición de los estilos de otros estilos de arquitectura o porque sus servicios se encuentran publicados. A continuación, se definirán los estilos de arquitecturas que pertenecen a esta categoría:

8.1.2.1 Arquitectura dirigida por eventos.

Este estilo de arquitectura representa el sistema en términos de generación, procesamiento, supervisión y cierre de eventos que pueden ocurrir en un sistema. Este estilo de arquitectura de software comprende capas lógicas. Un ejemplo de esta arquitectura es la API Java Swing. (Sharma et al., 2015). En la figura 5 se muestra un ejemplo de la estructura y los componentes de esta arquitectura.

Figura 5 Arquitectura dirigida por eventos (Sharma et al., 2015).

8.1.2.2 Estilo Publicación-Subscripción.

En este estilo de arquitectura los componentes interactúan anunciando eventos mientras que otros componentes se subscriben al grupo de eventos anunciados. Es el trabajo de la infraestructura de ejecución asegurarse que cada evento público es entregado a todos los subscritores de ese evento. En la figura 6 se muestran los principales componentes y la estructura que mantiene esta arquitectura. (Cossio et al., 2012; Rozanski & Woods, 2005; Sharma et al., 2015).

Figura 6 Estilo Publicación-Subscripción (Cossio et al., 2012; Sharma et al., 2015)


8.1.2.3 Mensajes Asíncronos.

En este estilo de arquitectura de software se resuelven muchos de los desafíos de la integración de sistemas dispares. Esta arquitectura es poderosa porque sus beneficios en la integración de sistemas han abierto un mercado significativo para los desarrolladores de software en la creación de middleware de mensajería y herramientas asociadas. En la figura 7 se muestran los principales componentes de esta arquitectura (Gregor, 2004).

Figura 7 Mensajes Asíncronos (Gregor, 2004).

8.1.3 Categoría Basados en Solicitud y respuesta

En esta categoría se encuentran los estilos de arquitectura que reciben una o varias peticiones y envían la respuesta ya sea una consulta o un servicio a los solicitantes. Estos estilos de arquitectura son los más usados actualmente ya que estos pueden contener otros estilos para su funcionamiento. A continuación, se definirán aquellos que pertenecen a esta categoría:

8.1.3.1 Estilo cliente-servidor.

En este estilo de arquitectura de software los clientes y los servidores interactúan mediante la solicitud de servicios de otros componentes. Los clientes son los solicitantes y los servidores son los proveedores, los cuales proveen un grupo de servicios a través de uno o más puertos. Hoy en día la mayor parte de las aplicaciones que se utilizan para acceder o que utilizan Internet están basados en el estilo cliente-servidor. En la figura 8 se muestran los principales componentes de esta arquitectura (Cossio et al., 2012; Sharma et al., 2015).


Figura 8 Estilo cliente-servidor (Cossio et al., 2012; Sharma et al., 2015)

8.1.3.2 Arquitectura SOA.

Este estilo de arquitectura de software es una colección distribuida de componentes que proveen y/o consumen servicios. En SOA los proveedores de servicios y los consumidores de servicios pueden usar diferentes implementaciones de lenguaje y plataformas. En la figura 9 se muestran los principales componentes de esta arquitectura (Cossio et al., 2012; C. Reynoso, 2004).

Figura 9 Estilo SOA (Cossio et al., 2012).

8.1.3.3 Estilo bróker.

Es un estilo de arquitectura de software con una estructura distribuida en la cual los componentes están desacoplados e interactúan mediante la invocación de servicios a distancia. El componente más significante es el bróker el cual distribuye las solicitudes del cliente a los servidores correspondientes y retorna sus correspondientes resultados (Dillon,


Wu, & Chang, 2007). En la figura 10 se muestran los principales componentes de esta arquitectura

Figura 10 Estilo bróker (Dillon et al., 2007).

8.1.3.4 Estilo punto a punto.

En este estilo de arquitectura de software se define un único tipo de elemento de sistema (peer) y un solo conector el cual es una conexión de red. El principio de este estilo es que cualquier par es libre para comunicarse directamente con cualquier otro par sin necesidad de un servidor. En la figura 11 se muestran los principales componentes de esta arquitectura (Cossio et al., 2012; Dillon et al., 2007; Rozanski & Woods, 2005).

Figura 11 Estilo par a par (Cossio et al., 2012; Dillon et al., 2007; Rozanski & Woods, 2005).

8.1.3.5 Arquitectura REST.

La arquitectura REST define recursos identificables y métodos para acceder y manipular los estados de los recursos. REST es la composición de estilos básicos incluyendo cliente-servidor, sistemas en capas y máquina virtual. REST utiliza un identificador de recursos llamados “URI” en el cual se proporciona un sello único para un recurso Web. En REST se acceden a los recursos mediante una interfaz genérica la cual reduce dramáticamente la


complejidad de la semántica de la interfaz durante la interacción de servicios, en la figura 12 se muestra la estructura y el flujo de los servicios Rest (Dillon et al., 2007; C. Reynoso, 2004).

Figura 12 Estilo REST (Dillon et al., 2007).

8.1.4 Categoría Basados en Memoria compartida

En esta categoría se encuentran los estilos de arquitectura que están basados en repositorios y que comparten datos, archivos, etc. Son usados como fuente de conocimiento y estos estilos pueden tener múltiples métodos de accesos los cuales pueden basarse en otros estilos de arquitectura. A continuación, se definirán los estilos de arquitecturas que pertenecen a esta categoría:

8.1.4.1 Estilo blackboard.

El estilo blackboard es un repositorio compartido y es utilizado por varias fuentes de conocimiento para resolver un problema. Cada fuente de conocimiento trata de resolver el problema y escribe en la pizarra su solución final, parcial o sugerencia, en la figura 13 se observan los componentes y la estructura del estilo. (Sharma et al., 2015).

Figura 13 Estilo blackboard (Sharma et al., 2015).


8.1.4.2 Estilo datos compartidos

Este estilo también es llamado estilo repositorio; en este estilo la interacción está dominada por el intercambio de datos persistentes. Estos datos tienen múltiples métodos de accesos y tiene al menos una unidad de datos centralizada, ver figura 14. (Cossio et al., 2012; Qin, Zheng, & Xing, 2008).

Figura 14 Estilo datos compartidos (Cossio et al., 2012).

8.1.5 Categoría Basados en Sistemas Adaptables

En esta categoría se encuentran los estilos de arquitectura que pueden ser adaptados y tener una mayor extensibilidad en el momento que se requiera. Estos estilos de arquitectura también contienen componentes y pueden estar contenidos dentro de otros estilos de arquitectura de software. A continuación, se definirán los estilos de arquitecturas que pertenecen a esta:

8.1.5.1 Microkernel.

La arquitectura microkernel es un modelo para la implementación de aplicaciones basadas en productos. Este patrón nos permite añadir características a la aplicación principal mediante plug-ins y de esta manera proporciona extensibilidad, aislamiento y separación. En la figura 15 se muestran los principales componentes de esta arquitectura (Richards, 2014).

Figura 15 Microkernel (Richards, 2014).


8.1.5.2 Microservice.

Hay varios conceptos básicos comunes que se aplican a este estilo de arquitectura de software. Uno de los conceptos es que las unidades se despliegan por separado, lo cual permite un despliegue más fácil, mayor escalabilidad y un alto grado de aplicación y descomposición de componentes dentro de la aplicación. Otro concepto a entender con esta arquitectura es la noción de componente de servicio. Los componentes de servicio pueden contener una o más módulos los cuales representan una función de un solo propósito o una parte independiente de una aplicación empresarial grande. Diseñar el nivel adecuado de un componente de servicio es uno de los desafíos más grandes dentro de la arquitectura de micro servicios (Richards, 2014). En la figura 16 se muestran los principales componentes de esta arquitectura.

Figura 16 Microservice - Y axis scaling – application level (Apply X axis cloning and/or Z partitioning to each service) (Richards, 2014).

Dentro de la tabla 1 se observará la clasificación de los estilos de arquitecturas de software de acuerdo a su categoría.

CATEGORÍA ESTILOS DE ARQUITECTURA DE

SOFTWARE

Basados en Componentes Estilo basado en componentes

Estilo de tuberías y filtros

Estilo sistema de capas

Basados en Mensajería Estilo Arquitectura dirigida por eventos

Estilo Publicación-Subscripción

Mensajes Asíncronos


Basados en Solicitud y Respuesta Estilo Cliente-Servidor

Estilo SOA

Estilo Bróker

Estilo Par a par

REST

Basados en Memoria Compartida Estilo Blackboard

Estilo Datos Compartidos

Basados en Sistemas Adaptables Microkernel

Microservice Tabla 1 Categorías de los estilos de arquitectura de software (Cossio et al., 2012; Dillon, Wu, & Chang, 2007; Gregor, 2004; Kumar, 2014; Qian, 2010; Qin, Zheng, & Xing, 2008; Reynoso, 2004; Richards, 2014; Rimal, Choi, & Lumb, 2009; Rozanski & Woods, 2005; Sha

8.2 Criterios de inclusión y exclusión de los estilos de arquitectura de software.

Teniendo en cuenta la clasificación realizada en la sección anterior, se realizará una selección de los estilos de arquitectura incluyendo únicamente los estilos de arquitectura orientados a la Web. Para realizar la selección de los estilos se usarán tres tipos de criterios, que son accedidos, consumidos y publicados en la Web.

1. Un estilo de arquitectura es Web si este puede ser accedido desde una URL en la Web.

2. Un estilo de arquitectura es Web si este estilo de arquitectura aparte de ser accedido, puede ser consumido por otro estilo de arquitectura que necesite de un servicio, o puede consumir un servicio de otro estilo de arquitectura mediante su URL, WSDL o una URI.

3. Un estilo de arquitectura es Web si este estilo de arquitectura puede ser

publicado en la Web mediante un servidor de aplicaciones, y puede permitir al estilo de arquitectura ser accedido y ser consumido por cualquier aplicación cliente que requiera de sus servicios.


CATEGORIA ESTILOS DE

ARQUITECTURA DE SOFTWARE

CRITERIO 1

CRITERIO 2

CRITERIO 3

BASADOS EN COMPONENTES

Estilo basado en componentes

Estilo tuberías y filtros

Estilo sistema en capas

BASADOS EN MENSAJERIA

Estilo de arquitectura dirigida por eventos

Estilo publicación-subscripción

Mensajes asíncronos

BASADOS EN SOLICITUD Y RESPUESTA

Estilo Cliente/Servidor X X X

Estilo SOA X X X

Estilo Bróker

Estilo punto a punto X X X

REST X X X

BASADOS EN MEMORIA

COMPARTIDA

Estilo blackboar

Estilo datos compartidos

BASADOS EN SISTEMAS

MODERNOS

Arquitectura Big Data

Arquitectura Cloud Computing

Arquitectura Grid Computing

BASADOS EN SISTEMAS

ADAPTABLES

Microkernel

Microservicio

Tabla 2 Selección de los estilos de arquitectura de software orientados a la Web.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

De acuerdo a la tabla 2 los estilos de arquitectura de software orientados a la Web son, cliente servidor, SOA, Rest y peer to peer, a continuación, se detalla el por qué cumplen estos estilos con los criterios.

1. El estilo cliente servidor aplica los tres criterios de selección ya que es un estilo de arquitectura que se puede publicar en la Web mediante un servidor de aplicaciones, también permite ser consumido por un cliente el cual puede ser un navegador web por medio de una URL y asimismo puede ser accedido desde cualquier navegador en cualquier dispositivo o por otra aplicación.(C. B. Reynoso, n.d.)

2. El estilo SOA del mismo modo le aplican los tres criterios de selección ya que este estilo de arquitectura puede ser publicado en la Web, puede ser


consumido por medio del WSDL y también puede ser accedido desde una aplicación de escritorio o de Smartphone hasta un navegador Web.

3. El estilo REST de igual forma le aplican los tres criterios de selección ya que este estilo de arquitectura puede ser publicado en la Web, puede ser consumido por medio de una URI y es accedido mediante una URL. Este estilo de arquitectura puede ser consumido desde cualquier aplicación desde que se tenga la llave de autorización necesaria para poder consumir sus servicios.(Roy T Fielding & Taylor, 1993)

4. El estilo punto a punto también aplica los tres criterios de selección ya que es

un estilo que puede ser accedido por múltiples clientes en la Web, es publicado en la Web para que sus servicios puedan ser consumidos por otros Pares y consumir los servicios de otros Pares en la Web.

De acuerdo a la descripción anterior los estilos de arquitectura que cumple con los criterios de inclusión y exclusión aplicados y serán objeto de análisis y estudio son los siguientes, ver tabla 3:

CATEGORÍA

ESTILOS DE ARQUITECTURA DE SOFTWARE

Basados en cliente-servidor

Cliente-Servidor

SOA

Peer to Peer

REST

Tabla 3 Estilos de arquitectura de Software en análisis.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

Una vez aplicados los criterios se puede evidencia que entre las categoría basada en cliente servidor tiene los estilos de arquitectura que son orientados a la Web, sin embargo también se puede evidencia que en las demás categorías aunque puede que apliquen al menos en un criterio, no son considerados Web ya que no cumplen los tres requisitos necesarios para que sean considerados Web ya que estos estilos pueden ser componentes o un medio de comunicación de los estilos de arquitectura seleccionado como Web.


9 APLICACIÓN METODOLOGÍA Y MODELO DE ANÁLISIS.

De acuerdo a la taxonomía identificada y los criterios de inclusión y exclusión aplicados, se obtuvieron cuatro estilos de arquitectura que son orientados a la Web que cumplían con estos, una vez identificados se procede a realizar un análisis de cada uno; para este proceso se realiza la aplicación de una metodología de meta análisis anteriormente expuesta, la cual se apoyará para la evaluación de los estilos sobre el modelo ATAM Architecture Trade-off Analysis Method - Análisis de Acuerdos de Arquitectura con la colaboración del modelo de McCall para el análisis cuantitativo.

9.1 Evaluación de los estilos arquitectónicos de software.

Se realizará el desarrollo de la evaluación de los estilos a partir de la aplicación del modelo ATAM, realizando la definición y aplicación de cada una de las fases del modelo por las que se debe pasar para obtener el análisis de resultados.

9.1.1 Modelo ATAM.

El nombre del método ATAM surge del hecho de que revela la forma en que una arquitectura específica satisface ciertos atributos de calidad, y provee una visión de cómo los atributos de calidad interactúan con otros; este se encuentra influido por tres áreas: los estilos arquitectónicos, el análisis de atributos de calidad y el método de evaluación SAAM, este último es un método de análisis de arquitecturas de software creado inicialmente para el estudio de la modificabilidad de una arquitectura, sin embargo ha sido muy útil para evaluar de forma ágil los atributos de calidad, como disponibilidad, portabilidad, escalabilidad e integralidad.(Nuñez, 2004)

Posteriormente se especificará y aplicará cada una de las fases de análisis del modelo ATAM, con el fin de iniciar con la evaluación de los estilos arquitectónicos seleccionados, conforme a lo anterior las fases a desarrollar son las siguientes:

9.1.2 Fase de presentación:

En esta fase se realizará la presentación e identificación de los estilos de arquitectura que se desean analizar; indicando el porqué de sus selección y si estos cumple con el caso de estudio en cuestión..(Nuñez, 2004); el desarrollo de esta fase hace referencia a la aplicación de los criterios de inclusión y exclusión en el numeral 8.2, en donde luego de correr los criterios seleccionados se obtienen los estilos orientados a la Web, los cuales son:

- Cliente/Servidor. - SOA. - Rest. - Peer to Peer.


9.1.3 Fase de análisis e investigación:

Esta fase iniciara con una investigación y especificación de los estilos a analizar indicando sus características, componentes, ventajas, desventajas y su funcionamiento; esto con el fin de tener un enfoque claro y detallado de cada uno; adicionalmente se realiza la asociación de los atributos de calidad a cada uno de ellos, representando como los atributos de calidad los afectan, esto con el fin poder realizar una análisis y priorización de los atributos con mayor influencia.(Delgado, Castro, & Germán, n.d.) Posteriormente se aplicara el modelo de McCall el cual describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios y métricas de calidad (Nuñez, 2004); este modelo permite cuantificar la calidad a partir de los atributos detallados en primera parte de la fase actual; el modelo se concentra en 3 aspectos principales características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.(Mccall & Richards, 1977)

9.1.3.1 Análisis de los estilos arquitectónicos orientados a la Web

A continuación, se realizará una descripción de los estilos a evaluar:

Estilo cliente-servidor.

ELEMENTOS

CLIENTE: Es el componente encargado de invocar los servicios publicados por el componente servidor.

SERVIDOR: Es el componente encargado de publicar los servicios a los componentes cliente.

CONECTOR PETICIÓN/RESPUESTA: Este conector es usado por el cliente para invocar los servicios de un servidor. Este conector tiene los roles de petición y respuesta. Las propiedades de los conectores incluyen cualquier llamada, ya sea local o remota y los datos están encriptados.

PARA QUÉ SIRVE

Promueve la modificación y la reutilización mediante la factorización de servicios comunes. Mejora la escalabilidad y la disponibilidad en caso de que la replicación del servidor esté en el sitio.

VENTAJAS

Escalabilidad ya que se puede aumentar la capacidad de los clientes y servidores.

Es de fácil mantenimiento.

Centralización en el control de datos, recursos e integridad. También ayuda a mantener al día los datos.

DESVENTAJAS

Una de sus principales desventajas son la congestión de datos.

Otra principal desventaja es cuando el servidor está caído las peticiones de los clientes no pueden ser respondidas.

Tabla 4 Estilo cliente-servidor (Cossio et al., 2012; Garlan et al., 2009; Garlan & Shaw, 1994; Kumar, 2014; Qin et al., 2008; Sharma et al., 2015).


Estilo arquitectura orientada a servicios SOA.

ELEMENTOS

PROVEEDORES DE SERVICIOS: Son los que proveen uno o más servicios a través de la publicación de interfaces.

CONSUMIDORES DE SERVICIOS: Son los que invocan los servicios directamente o a través de un intermediario.

ESB: Es un elemento intermediario que puede enrutar y transformar los mensajes entre los proveedores de los servicios y los consumidores de los servicios.

REGISTRO DE SERVICIOS: Pueden ser usados por los proveedores para registrar sus servicios y por los consumidores para consultar y localizar los servicios en tiempo de ejecución.

SERVIDOR DE ORQUESTACIÓN: Coordina la interacción entre los consumidores de servicio y los proveedores basados en las secuencias de comandos que definen los flujos de trabajo de los negocios.

CONECTOR SOAP: Usa los protocolos SOAP para la comunicación sincrónica entre los servicios Web.

CONECTOR REST: Está basado en las operaciones solicitud/respuesta del protocolo HTTP.

CONECTOR DE MENSAJERÍA: Usa un sistema de mensajería para ofrecer intercambios de mensajes asíncronos.

PARA QUÉ SIRVE

Permite la interoperabilidad de los componentes distribuidos ejecutados en diferentes plataformas o en INTERNET.

Integra sistemas heredados Permite una reconfiguración dinámica.

VENTAJAS

Mejora en los tiempos de cambios de procesos.

Facilidad para la evolución de nuevos modelos de negocio.

Facilidad para la integración de tecnologías.

DESVENTAJAS

Requiere un alto esfuerzo por parte de las organizaciones realizar el cambio a SOA.

La velocidad de intercambio de los datos es más lenta que haciendo el intercambio de forma directa.

Tabla 5 Estilo de arquitectura orientado a servicios (Cossio et al., 2012; Garlan et al., 2009; Garlan & Shaw, 1994; Kumar, 2014; Qin et al., 2008; Sharma et al., 2015)

Estilo peer to peer.

ELEMENTOS

Componente PAR.

CONECTOR LLAMADA/RETORNO: Este conector es usado para conectar el PAR a la red, realiza la búsqueda de otros pares e invoca los servicios esos pares.

PARA QUÉ SIRVE Proporciona una mayor disponibilidad.

Proporciona una mayor escalabilidad.


Activación de sistemas altamente distribuidos, tales como compartir archivos y mensajería instantánea.

VENTAJAS Permite el intercambio directo de cualquier tipo de dato.

Si un componente se desconecta de la red, la transmisión de los datos se sigue efectuando

DESVENTAJAS Entre más grande sea la red más difícil será controlar y

coordinar el sistema.

El sistema al seguir creciendo, disminuirá la seguridad. Tabla 6 Estilo peer to peer (Cossio et al., 2012; Garlan et al., 2009; Garlan & Shaw, 1994; Kumar, 2014;

Qin et al., 2008; Sharma et al., 2015).

Estilo Rest.

ELEMENTOS

Recursos.

Servidores proxy.

El sistema puede estar basado en la arquitectura cliente servidor por lo tanto pueden compartir sus mismos componentes.

PARA QUÉ SIRVE

Los REST publican recursos que pueden ser accedidos para la obtención de datos o indicar operaciones sobre los datos en cualquier formato (XML, JSON, HTML, TEXTO PLANO).

VENTAJAS

Separación del cliente-servidor ya que al cliente no le importa cómo está hecha la API y al servidor no le importa lo que el cliente va a hacer con los recursos

Si necesita evolucionar se puede hacer de manera separada.

Independencia de tecnologías y lenguajes

Fiabilidad, escalabilidad y flexibilidad.

DESVENTAJAS

Puede producirse circunstancias de mayor rigidez sobre todo al tener proyectos independientes.

Requiere más conocimientos para desarrollarlo.

Puede incurrir en mayores tiempos de desarrollo. Tabla 7 Estilo Rest (Cossio et al., 2012; Garlan et al., 2009; Garlan & Shaw, 1994; Kumar, 2014; Qin et al.,

2008; Sharma et al., 2015).

9.1.3.2 Atributos de calidad de los estilos arquitectónicos orientados a la Web

Luego de realizada la explicación de los estilos arquitectónicos se procede a generar la relación de los atributos de calidad con cada uno de los estilos, esto debido a que el modelo indica que se deben listar los atributos de calidad que engloban la utilidad de los estilos, especificados en forma de escenarios o criterios (Nuñez, 2004); es decir, se listaran los atributos de calidad y se realizará una descripción de cada uno de ellos con el fin de establecer unos criterios que más adelante serán utilices para la priorización y cuantificación en la evaluación.


Atributos de calidad para SOA.

La tabla 8 describe algunos de los atributos de calidad que impulsan el diseño de arquitecturas SOA. Cada atributo permite describir los requisitos que soporta SOA. Esta arquitectura tiene una gran flexibilidad y evolución, aunque es todavía una tecnología emergente, ya que los problemas entre SOA y los atributos de calidad no se han investigado a fondo.(Brien & Merson, 2005)

Atributo de calidad SOA

Disponibilidad

Contingencias para el manejo de excepciones cuando un servidor no está disponible

Establecimiento de niveles acordados de disponibilidad

Confiabilidad Mensajes admitidos de forma fiable

Interoperabilidad Interacción en las diferentes plataformas

Seguridad No cuenta con una seguridad total, las normas que apoyan la seguridad de las arquitecturas se encuentran en desarrollo

Rendimiento

Retrasos en la red

Sobrecarga de búsqueda de servicios de un directorio

Escabilidad Aumento en número de usuarios de servicio y la incorporación de capacidades adicionales Tabla 8 Atributos SOA (Brien & Merson, 2005)

Atributos de calidad de cliente / servidor.

En la tabla 9 se describe los atributos de calidad pertenecientes a la arquitectura cliente/servidor, donde se puede observar que esta arquitectura contiene módulos independientes que pueden reemplazarse sin afectarse, permitiendo así satisfacer necesidades cambiantes, creando nuevos módulos o realizando cambios a los existentes.(Edgar & Luis, 1997)

Atributo de calidad Cliente/ Servidor

Disponibilidad Recuperación y el restablecimiento de las operaciones, utilizando los recursos de los clientes

Confiabilidad Falta de confiabilidad cuando se les compara con los ambientes multiusuario tradicionales


Interoperabilidad Relación entre los clientes y los servidores.

Seguridad Datos en el servidor permitiendo el incremento de seguridad

Rendimiento Incremento de velocidad y la cantidad de tráfico en la red disminuye

Escabilidad Satisfacción de las necesidades cambiantes de las empresas Replicación de aplicación

Tabla 9 Atributos Cliente Servidor (Edgar & Luis, 1997)

Atributos de calidad para peer to peer.

Para la arquitectura peer to peer se contemplan ciertos atributos, entre ellos cuenta con intercambio de información, mayor velocidad, nivel bajo de seguridad ya que comparten información, alta disponibilidad ya que, si el servidor se cae, se pasa a otro servidor. En la tabla 10 se describen algunos atributos de calidad.(Kicillof, 2004).

Atributo de calidad Peer To Peer

Disponibilidad Mayor tolerancia a fallos, evitando perdida de información por desconexión de nodos y caídas en la red

Confiabilidad Información distribuida de forma flexible haciendo que su control sea complicado

Interoperabilidad Coordinación entre procesos de servidor descentralizado

Seguridad Identificar y evitar los nodos maliciosos, evitar el contenido infectado

Rendimiento Desarrollo en paralelo, permitiendo mejoras en el rendimiento

Capacidad de almacenamiento

Escabilidad Reducción de ineficiencias y recursos desperdiciados de los sistemas centralizados Tabla 10 Atributos Peer to Peer (Kicillof, 2004)

Atributos de calidad para rest.

Rest permite guiar el diseño y desarrollo de la arquitectura de la web moderna. Enfatiza la escalabilidad de interacciones en componentes, por otra parte, esta arquitectura es capaz de comunicar los datos de autenticación y controles de autorización, permite manejar los proxys como intermediarios mejorando la seguridad, sin embargo, genera sobrecargas por interacciones disminuyendo el performance. (Roy Thomas Fielding, 2000)


Atributo de calidad REST

Disponibilidad Disponibilidad de información de dimensiones visuales de los objetos en línea

Confiabilidad Aplicaciones intermedias capaces de inspeccionar las interacciones de aplicaciones

Interoperabilidad Interconexión a través de múltiples dominios de confianza

Seguridad Manejo de proxys como intermediarios para encapsulación de interfaz de otros servicios, conversión de datos, y mejorar la seguridad

Rendimiento

La optimización del rendimiento del navegador se centra en la reducción de esta latencia de las comunicaciones.

Disminuir el rendimiento de la red mediante el aumento de los datos repetitivo (Sobrecarga por interacción) enviado en una serie de peticiones

Escabilidad Escalabilidad de las interacciones de los componentes

Tabla 11 Atributos REST (Roy Thomas Fielding, 2000)

9.1.3.3 Aplicación de modelo Mccall a los atributos de calidad.

Una vez realizada la descripción de la afectación de los atributos de calidad en los diferentes estilos se procede a realizar la aplicación del modelo de MCcall el cual da a conocer el término de factor de calidad el cual define características claves que un estilo debe exhibir. Los atributos de calidad que se definen, son los nombrados criterios de calidad, y las métricas de calidad pueden ser utilizadas para cuantificar los criterios de acuerdo al cumplimiento de cada uno de estos.(Nuñez, 2004) En la tabla 12 se dan a conocer los criterios de calidad para cada uno de los atributos de calidad que se ha venido estudiando.

Atributo de calidad Criterios

Disponibilidad * Completitud

* Restablecimiento * Concurrencia

Confiabilidad * Consistencia

* Exactitud * Tolerancia a fallas

Interoperabilidad * Modularidad

* Similitud de comunicación * Similitud de datos

Seguridad * Operabilidad

* Entrenamiento * Comunicación


Rendimiento * Eficiencia de ejecución

* Eficiencia de almacenamiento

Escabilidad * Capacidad de Expansión

* Generalidad * Modularidad

Tabla 12 Criterios de calidad por atributo(Mccall & Richards, 1977; Nuñez, 2004)

El modelo de Mccall propone realizar la división de la suma de las métricas que cubren los aspectos de calidad “criterios” entre el número total de los aspectos a evaluar “atributos” con el fin de obtener el valor del criterio, es decir la suma de los criterios divido el número total de los aspectos y factores a evaluar. (Mccall & Richards, 1977)

- Atributos = 6 - Criterios = 18

Valor Criterio (VC) = 18/6= 3 De acuerdo a lo anterior se identifica de cada criterio tiene un valor de 3 puntos, en donde 1 punto es bajo, 2 es medio y 3 es alto. A continuación se realizará la cuantificación de cada uno de los criterios de calidad vs los atributos de calidad por estilo, teniendo en cuenta el cumplimiento de los criterios para con los atributos, es decir que se le indicará un peso a los criterios de acuerdo al nivel de completitud que se tenga frente a los atributos de calidad, esto con el fin de generar un análisis de los estilos arquitectónicos, sin embargo siguiendo con las fases del modelo ATAM, se deberá realizar el desarrollo del análisis en una tercera fase llamada pruebas, sin embargo esta fase no se realizará como la sustenta el modelo puesto que debido al alcance del proyecto y los tiempos establecidos no se puede cumplir a cabalidad generando pruebas de cada una de los estilos sobre un determinado software, adicionalmente ATAM es un modelo que genera una evaluación de las arquitecturas basado en escenarios, evaluados cualitativamente y como el objetivo es realizarlo de forma cuantitativa, se aplicó el modelo Mccall, por lo tanto se procede a continuar con la última fase del modelo llamada reporte y que para esta evaluación será llamada análisis de resultados.

9.1.4 Fase análisis de resultados

En esta fase se realizará la presentación de los resultados y los hallazgos encontrados.(Nuñez, 2004), producto de la aplicación del modelo de Mccall y la investigación realizada, donde se indica el peso que tiene cada criterio para cada uno de los atributos de calidad por estilo, esto basado en la investigación de cada uno, la relación con cada atributo de calidad y el criterio del equipo de trabajo; una vez obtenido esto, se genera un promedio por estilo arquitectónico y se evidencia cual es el que más se destaca por atributo de calidad;


posteriormente se presentan los estilos que obtuvieron mayor puntaje por atributo de calidad, con el fin generar finalmente un ranking que indique cual es el estilo que mejor desempeño tiene al ser implementado en la Web. De acuerdo a lo anterior se procede a realizar inicialmente, la presentación del análisis de los resultados por atributo de calidad de acuerdo a los criterios fijados y evaluados por estilo arquitectónico.

9.1.4.1 Análisis disponibilidad.

La tabla 13 hace referencia al atributo de calidad disponibilidad, el estilo Peer to Peer tiene una mejor disponibilidad ya que es un estilo de arquitectura que es más tolerante a los fallos debido a que si un nodo no puede estar disponible o se desconecta hay uno o más nodos que pueden reemplazar el trabajo que estaba realizando el nodo.

Atributos Estilos Descripción

Atributo Criterios Puntaje Promedio

Disponibilidad

SOA

* Contingencias para el manejo de excepciones

cuando un servidor no está

disponible *

Establecimiento de niveles

acordados de disponibilidad

Completitud 2

2,333

Restablecimiento 3

Concurrencia 2

Cliente/ Servidor

* Recuperación y el

restablecimiento de las

operaciones, utilizando los

recursos de los clientes

Completitud 2

2

Restablecimiento 2

Concurrencia 2

REST

Disponibilidad de información de dimensiones visuales de los objetos en línea

Completitud 2

2,33 Restablecimiento 2

Concurrencia 3

Peer To Peer

Mayor tolerancia a

fallos evitando perdida de

información por

Completitud 3

3 Restablecimiento 3

Concurrencia 3


desconexión de nodos y caídas

en la red

Total Promedio 2,416 Tabla 13 Cuantificación Disponibilidad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

9.1.4.2 Análisis confiabilidad

En la tabla 14 se observan los resultados obtenidos para el atributo de calidad confiabilidad Los estilos SOA y Peer to Peer empatan en sus resultados ya que estos dos estilos de arquitectura tienen más consistencia y exactitud en el envío de mensajes e información distribuida y son seguidos muy de cerca por el estilo REST ya que como se observa tiene unos puntajes más intermedios que los de cliente servidor.

Atributos Estilos Descripción Atributo Criterios Puntaje Promedio

Confiabilidad

SOA Mensajes admitidos de

forma fiable

Consistencia 3

2,333 Exactitud 2

Tolerancia a fallos

2

Cliente/ Servidor

Falta de confiabilidad cuando se les compara

con los ambientes multiusuario tradicionales

Consistencia 2

1,666 Exactitud 2

Tolerancia a fallos

1

REST

Aplicaciones intermedias capaces de

inspeccionar las interacciones de

aplicaciones

Consistencia 2

2 Exactitud 2

Tolerancia a fallos

2

Peer To Peer

Información distribuida de forma flexible

haciendo que su control sea complicado

Consistencia 2

2,333 Exactitud 2

Tolerancia a fallos

3

Total Promedio 2,083 Tabla 14 Cuantificación Confiabilidad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

9.1.4.3 Análisis interoperabilidad

La tabla 15 hace referencia a la evaluación del atributo de calidad Interoperabilidad en donde se observa nuevamente un empate con una máxima calificación entre las arquitecturas SOA y REST ya que estos dos estilos de arquitectura permiten la interacción entre diferentes plataformas y la interconexión entre diferentes aplicaciones a través de múltiples dominios.


Le sigue muy de cerca el estilo de arquitectura Peer to Peer ya que no necesita de un servidor centralizado y se centra en una mejor coordinación de los procesos de cada Nodo.



Interoperabilidad

SOA Interacción en las diferentes plataformas

Modularidad 3

3 Similitud de

comunicación 3

Similitud de datos

3

Cliente/ Servidor

Relación entre los clientes y los

servidores.

Modularidad 2

2 Similitud de

comunicación 2

Similitud de datos

2

REST

Interconexión a través de múltiples

dominios de confianza

Modularidad 3

3 Similitud de

comunicación 3

Similitud de datos

3

Peer To Peer

Coordinación entre procesos

de servidor descentralizado

Modularidad 3

2,333 Similitud de

comunicación 2

Similitud de datos

2

Total Promedio 2,583 Tabla 15 Cuantificación Interoperabilidad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

9.1.4.4 Análisis seguridad

De acuerdo a los resultados obtenidos en la siguiente tabla 16 relacionada al atributo de calidad seguridad se observa que el estilo de arquitectura REST tiene una mejor seguridad respecto a las demás ya que puede utilizar proxys intermediarios y certificados SSL y conversión de datos y la arquitectura Peer to Peer tiene la peor seguridad ya que no garantiza que nodo tiene algún virus malicioso.


Atributos Estilos Descripción Atributo Criterios Puntaje Promedio

Seguridad

SOA

No cuenta con una seguridad total, las

normas que apoyan la seguridad de las arquitecturas se

encuentran en desarrollo

Operabilidad 2

2,333

Entrenamiento 2

Comunicación 3

Cliente/ Servidor

Datos en el servidor permitiendo el incremento

de la seguridad

Operabilidad 2

1,666 Entrenamiento 1

Comunicación 2

REST

Manejo de proxys como intermediarios para

encapsulación de interfaz de otros servicios,

conversión de datos, y mejorar la seguridad

Operabilidad 3

2,666

Entrenamiento 2

Comunicación 3

Peer To Peer

Identificar y evitar los nodos maliciosos, evitar el contenido infectado

Operabilidad 1

1 Entrenamiento 1

Comunicación 1

Total Promedio 1,916 Tabla 16 Cuantificación seguridad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

9.1.4.5 Análisis rendimiento

Los resultados obtenidos en la tabla 17 asociado al atributo de calidad rendimiento evidencia que el estilo Peer to Peer tiene un mejor rendimiento ya que tiene una capacidad de almacenamiento el cual depende de la cantidad de nodos conectados, además permite el desarrollo en paralelo y es un estilo de arquitectura eficiente en la ejecución y el almacenamiento de datos.



Rendimiento

SOA

* Retraso en la Red.

* Sobrecarga en la búsqueda de servicios de un

directorio

Eficiencia de Ejecución

2

2

Eficiencia de almacenamiento

2

Cliente/ Servidor

Incremento de velocidad y la

cantidad de tráfico


1

1 Eficiencia de

almacenamiento 1


en la red disminuye

REST

* La optimización del rendimiento

del navegador se centra en la

reducción de esta latencia de las

comunicaciones. * Disminuir el

rendimiento de la red mediante el aumento de los datos repetitivo (Sobrecarga por

interacción) enviado en una

serie de peticiones


2

2,5


3

Peer To Peer

* Desarrollo en paralelo,

permitiendo mejoras en el rendimiento

* Capacidad de almacenamiento


2

2,5


3

Total Promedio 2 Tabla 17 Cuantificación rendimiento. (Juan C . Cardenas F; Christian R. Chacon P, 2017)

9.1.4.6 Análisis escalabilidad

En la tabla 18 se destaca el atributo de calidad Escalabilidad, el estilo de arquitectura con mayor escalabilidad es REST ya que tiene un buen manejo de crecimiento continuo de trabajo ya que sin importar su crecimiento no pierde la calidad de los servicios que ofrece. Le sigue el estilo SOA y Peer to Peer ya que estos estilos a pesar crecer continuamente y de aumentar el número de usuarios no pierden eficiencia en la respuesta de las solicitudes de servicio y de recursos y permiten la incorporación de capacidades y nodos adicionales.



Escalabilidad SOA

Aumento en número de usuarios de servicio y la

incorporación

Capacidad de Expansión

3

2,333 Generalidad 2

Modularidad 2


de capacidades adicionales

Cliente/ Servidor

Satisfacción de las necesidades cambiantes de las empresas


2

1,666 Replicación de

aplicación Generalidad 1

Modularidad 2

REST

Escalabilidad de las

interacciones de los

componentes


3

3 Generalidad 3

Modularidad 3

Peer To Peer

Reducción de ineficiencias y

recursos desperdiciados de los sistemas centralizados


3

2 Generalidad 1

Modularidad 2

Total Promedio 2,25 Tabla 18 Cuantificación escalabilidad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

En la tabla 19 se identifican los estilos arquitectónicos con mayores puntajes para cada uno de los atributos de calidad.

Atributos De Calidad Estilos De Arquitectura De

Software Puntaje

Disponibilidad Peer to Peer 3

Confiabilidad SOA 2,3

Peer to Peer 2,3

Interoperabilidad SOA 3

REST 3

Seguridad REST 2,6

Rendimiento REST 2,5

Peer to Peer 2,5

Escalabilidad REST 3 Tabla 19 Estilos destacados por atributo de calidad.(Juan C . Cardenas F; Christian R. Chacon P, 2017)

Finalmente se procede a realizar un ranking de los estilos arquitectónicos de software orientados a la Web que tuvieron la mejor puntuación y figuración en la evaluación previamente realizada, ver tabla 20.


Estilos De Arquitectura De Software Ranking

REST 1

Peer to Peer 2

SOA 3 Tabla 20 Ranking de los estilos arquitectónicos. (Juan C . Cardenas F; Christian R. Chacon P, 2017)

De acuerdo a la tabla anterior se puede observar que el estilo de arquitectura REST está de primero ya que cumple con 4 de 6 atributos de calidad, lo cual muestra que es un estilo que puede proporcionar una mayor estabilidad y una mejor calidad a la hora de implementarse en los diferentes entornos de negocio de software. De segundo se tiene al estilo Peer to Peer el cuál cumple con 3 de los 6 estilos de arquitectura de software y aunque no ocupa el primer lugar es interesante ver que este estilo cumple con tres de los atributos más importantes en el desarrollo de software, demostrando así que es un estilo de software tolerante a los fallos, es confiable y su rendimiento es excelente para soluciones de software que necesiten una alta disponibilidad y confiabilidad. Por último está el estilo de arquitectura SOA el cual a pesar de ser uno de los estilos que se utilizan más en la integración de servicios en las empresas, de acuerdo a esta tabla es un estilo de arquitectura que solo ofrece confiabilidad e interoperabilidad en la soluciones de software. Por esta razón actualmente las empresas desarrolladoras de software recomiendan utilizar REST en vez de SOA ya que este estilo ofrece soluciones de negocio sostenible y escalable de acuerdo a las necesidades del mismo.

Los arquitectos de software y desarrolladores a partir de esta evaluación tendrán una guía, que les será de ayuda a la hora de tomar una decisión de que estilo de software implementar para un desarrollando sobre la Web, así como también tendrán una visión de que estilo de software tiene un mejor desempeño para un determinado atributos de calidad, lo que es importante a la hora de cumplir con los requerimientos no funcionales de un proyecto.


10 TRABAJOS FUTUROS

De acuerdo al análisis realizado, se obtuvo un análisis de resultados de cuáles son los estilos

arquitectónicos orientados a la Web, cuáles de ellos son los que mejor tienen un desempeño

y que estado actual tienen, de acuerdo a los atributos de calidad y los criterios de evaluación

seleccionados, sin embargo este es solo el inicio de una evaluación, puesto que a futuro los

arquitectos de software y los desarrolladores, pueden generar un estudio a partir del

comportamiento que tienen estos estilo sobre una misma aplicación, es decir, implementar

cada uno de estos estilos en el desarrollo de un mismo software, con el fin de generar una

evaluación práctica y que confirme los resultados que se evidencia aquí.

Adicionalmente en un futuro se pueden realizar análisis y comparaciones entre los estilos

orientados a la Web y los que no son, con el fin de obtener una nueva validación que les

permita a los interesados poseer más bases y fuentes para los futuros desarrollos y las

nuevas tecnologías.


11 CONCLUSIONES

Por medio de la investigación realizada a los estilos arquitectónicos existentes y aplicando criterios de inclusión y exclusiones, se identificó que REST, SOA, Peer to Peer y cliente- Servidor son los estilos que se encuentran orientados a la web, y por lo tanto se establecieron como objeto de estudio para este proyecto.

Métodos como ATAM permiten llevar un paso a paso y guiar al equipo de trabajo a realizar la evaluación de los estilos arquitectónicos de una forma estructurada y metodológica permitiendo así generar resultados concretos.

Utilizando modelos como Mccall se puede llegar a realizar un análisis cuantitativo sobre los estilos arquitectónicos de software, ya que este cuenta con unos criterios propios de evaluación que permiten definir prioridades para cada uno de los atributos de calidad y así establecer cuál es la mejor opción para implementar en un entorno Web.

De acuerdo al análisis realizado, aplicando los modelos ATAM y Mccall, se determina que el estilo con mayor calidad, escalabilidad y rendimiento a la hora de implementarlo en diferentes entornos de software orientados a la web, es REST, ya que este cumple el mayor puntaje en 4 de los 6 atributos sobre los que fue evaluado.

El correcto uso de los estilos arquitectónicos en el desarrollo de software permite a las organizaciones obtener un producto con mayor rendimiento, cumpliendo así 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 así obtener el éxito del proyecto.


12 REFERENCIAS

Albin, S. T. (2003). The Art of Software.

Arias, Y. M. (2013). Estilo arquitectónico para el sistema integrado de gestión Cedrux, 1(1), 24–36.

Bash, E. (2015). Addison Wesley - Software Architecture In Practice 2nd Edition. PhD Proposal (Vol. 1). http://doi.org/10.1017/CBO9781107415324.004

Bertoa, M. F. (2003). Atributos de Calidad para Componentes COTS.

Bosch, J. (2004). Software Architecture : The Next Step, 194–199.

Brien, L. O., & Merson, P. (2005). Quality Attributes and Service-Oriented Architectures, (September).

Committee, P. P. (2004). Guide to the Software Engineering Body of Knowledge.

Cossio, M. L. T., Giesen, L. F., Araya, G., Pérez-Cotapos, M. L. S., VERGARA, R. L., Manca, M., … Héritier, F. (2012). Documenting Software Architectures Views and Beyond. Uma Ética Para Quantos?, XXXIII(2), 81–87. http://doi.org/10.1007/s13398-014-0173-7.2

Cristi, M. (2006). Cat ´ alogo Incompleto de Estilos Arquitect ´ onicos.

Cristi, M. (2014). Introduccion a la Arquitectura de Software Introducci ´ on a la Arquitectura de Software no en el ciclo de vida del sistema, (January 2008).

Delgado, A., Castro, A., & Germán, M. (n.d.). Evaluación de Arquitecturas de Software con ATAM ( Architecture Tradeoff Analysis Method ): un caso de estudio.

Dillon, T. S., Wu, C., & Chang, E. (2007). Reference Architectural Styles for Service-Oriented Computing, 543–555.

Dong, J., & Chen, S. (2005). Event-Based Blackboard Architecture for Multi-Agent Systems.

Edgar, L., & Luis, I. (1997). Cliente/servidor.

Española, R. A. (2016). RAE.

Fernando, X., Peña, C., Inés, V., Mieles, C., Lucía, C., & Robalino, A. (2006). Diseño y Desarrollo de una Aplicación P2P de Mensajería para la ESPOL , Usando Tecnología JXTA, 19, 93–98.

Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures.


Fielding, R. T., & Taylor, R. N. (1993). Principled Design of the Modern Web Architecture.

Garlan, D., & Garlan, D. (2000). Software Architecture : a Roadmap Software Architecture : a Roadmap.

Garlan, D., & Shaw, M. (1994a). An Introduction to Software Architecture. Knowledge Creation Diffusion Utilization, 1(January), 1–40. Retrieved from http://portal.acm.org/citation.cfm?id=865128

Garlan, D., & Shaw, M. (1994b). An Introduction to Software Architecture, (January).

Gregor, B. (2004). Enterprise Integration Patterns.

Ing, R. S., & Rienzi, B. (2009). 7. Introducción a los Sistemas de Información, Arquitectura de Software, Integración de Sistemas y Middleware.

J, I. J. R., & Sc, M. (2009). Arquitectura Orientada a Servicios.

Juan C . Cardenas F; Christian R. Chacon P. (2017). Meta Analisis De Los Estilos De Arquitectura De Software Orientados A La Web.

Kicillof, C. R. – N. (2004). Estilos y Patrones en la Estrategia de Arquitectura de Microsoft Estilos arquitectónicos, version 1., 1–73.

Klein, M. H., Kazman, R., Bass, L., Carriere, J., Barbacci, M., & Lipson, H. (2008). Chapter Attribute-Based Architecture Styles, 1–20.

Kruchten, P. (1995). Architectural Blueprints — The “ 4 + 1 ” View Model of Software Architecture, 12(November), 42–50.

Kumar, A. (2014). Software Architecture Styles a Survey, 87(9), 5–9.

Mccall, J. A., & Richards, P. K. (1977). Concept and Definitions of Software Quality, I(November).

Mora, J. T. (2011). Arquitectura de software para aplicaciones Web, 1, 150.

Nuñez, E. C. F. C. G. (2004). Arquitecturas de software g, 1–58.

Perry, D. E., Laboratories, T. B., Hill, M., & Wolf, A. L. (1992). Foundations for the study of software architecure, 17(4).

Qin, Z., Zheng, X., & Xing, J. (2008). Software Architecture. http://doi.org/10.1007/978-3-540-74343-9

Rapanotti, L., Hall, J. G., Jackson, M., Nuseibeh, B., Hall, W., Keynes, M., … Nuseibeh, B. A. (2004). Architecture-driven Problem Decomposition.

Reynoso, C. (2004). Introducción a la Arquitectura de Software. Universidad de Buenos Aires.


Reynoso, C. B. (n.d.). Introducción a la Arquitectura de Software.

Richards, M. (2014). Software Architecture Patterns (DRAFT). O’Reilly (Vol. 32). http://doi.org/10.1097/NHH.0000000000000071

Rozanski, N., & Woods, E. (2005). Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Viewpoints, 8(2), 576.

Sánchez-meca, J. (2010a). C{ó}mo realizar una revisi{ó}n sistem{á}tica y un meta-an{á}lisis *, 38, 53–63.

Sánchez-meca, J. (2010b). Cómo realizar una revisión sistemática y un meta-análisis *, 38, 53–63.

Sánchez, J. (2013a). Por qu{é} Investigar y C{ó}mo Conducir una Investigaci{ó}n, 31(4), 1498–1504. http://doi.org/10.4067/S0717-95022013000400056

Sánchez, J. (2013b). Por qué Investigar y Cómo Conducir una Investigación, 31(4), 1498–1504. http://doi.org/10.4067/S0717-95022013000400056

Schollmeier, R., Networks, C., & Universität, T. (2002). A Definition of Peer-to-Peer Networking for the Classification of Peer-to- Peer Architectures and Applications, 2–3.

Science, C. (1999). Design and Evaluation of Software Architecture.

Sharma, A., Kumar, M., & Agarwal, S. (2015). A Complete Survey on Software Architectural Styles and Patterns. Procedia - Procedia Computer Science, 70, 16–28. http://doi.org/10.1016/j.procs.2015.10.019

Son, Q. U. É., & Revisiones, L. A. S. (2005). ¿qué son las revisiones sistematicas?, 1–6.

Taylor, R. N. (2009). Architectural Styles for Runtime Software Adaptation, 10.

View, M., Lu, G. N., Carlton, E. H., & Carlos, S. (2003). CLIENT-SERVER COMPUTER NETWORK MANAGEMENT ARCHITECTURE, 1(12).

White, S. A. (1995). The software architecture process.


13 GLOSARIO

Arquitectura de Software: La arquitectura de software es la descomposición de un sistema

de nivel superior en cada uno de sus componentes principales, las interfaces y su

comunicación(Garlan & Shaw, 1994b).

Estilos de Arquitectura de Software: Un estilo de arquitectura se define como como una

familia de sistemas con patrones comunes de una organización estructurada(Garlan & Shaw,

1994b).

Taxonomía: La taxonomía es un método de clasificación de acuerdo a las características,

similitudes o diferencias, en las especies biológicas(Española, 2016).

SOA: Arquitectura Orientada a Servicios, es un estilo de arquitectura que se basa en la

comunicación de varios sistemas de información independientes desarrollados en diferentes

lenguajes, desplegados en diferentes servidores de aplicaciones, ejecutados en diferentes

Sistemas Operativos, y con motores de base de datos diferentes, los cuales se pueden

comunicar por la red para ofrecer sus funcionalidades por medio de publicación de servicios.

(J & Sc, 2009)

REST: Transferencia de Estado Representacional, la arquitectura REST define recursos

identificables y métodos para acceder y manipular los estados de los recursos(Dillon et al.,

2007; C. Reynoso, 2004)

Asíncrono: Que no tiene lugar en completa correspondencia temporal con otro proceso o

con la causa que lo produce(Española, 2016).

Software: Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas

tareas en una computadora (Española, 2016).

Meta análisis: Es una metodología que tiene como propósito integrar de forma objetiva y

sistemática los resultados de los estudios empíricos sobre un determinado problema de

investigación, con objeto de determinar el estado del arte en ese campo de estudio

(Sánchez-meca, 2010a; Sánchez, 2013a).

Revision Systematic: Un meta-análisis es una revisión sistemática en el cual se combinan

los resultados de varios estudios que examinan la misma pregunta. Es una disciplina que

revisa la literatura críticamente y combina estadísticamente los resultados de estudios

previos. Se trata de resumir en un valor numérico toda la evidencia relacionada a un tópico

específico.(Son & Revisiones, 2005)


Atributos de Calidad: Los atributos de calidad ayudan en la selección de componentes y

medir un sistema, entre los atributos más utilizados se tiene: Funcionalidad, Rendimiento,

Fiabilidad, escalabilidad.(Bertoa, 2003)g

meta anÁlisis de los estilos de arquitectura de … · detallados, esto con el fin de realizar un...

Documents