Informe Exposición Arquitecturas de Software

Por: Esteban Novoa Quiñones, Jorge Steveen Ayala Benitez, Henry Duvan Bonilla
Urrego

Arquitectura Microkernel

Esta es una arquitectura basada en la descomposición por componentes, separa de

igual manera los componentes según su función ya sea si se parte del núcleo
funcional o plugins.Esta separación y clasificación de componentes ayuda al que la
arquitectura del sistema esté dispuesta para cambios de los requisitos del cliente y
facilite dar al sistema una propiedad de extensibilidad lo que representa el fácil
desarrollo de plugins que proporcionan nuevas funciones al producto.

Este es un patrón de arquitectura orientada para aplicaciones basadas en productos

y como lo mencionamos anteriormente esta arquitectura categoriza los
componentes:

· Componentes del núcleo del sistema: Estos componentes son el sistema

central del sistema, este conjunto de componentes representan la aplicación
básica que tenemos, contendrán las funciones principales y presentarán los
componentes esenciales para que la aplicación pueda funcionar de manera
adecuada.

· Módulos enchufables o plug ins: Básicamente son módulos adicionales a la

aplicación que proveen funcionalidades complementarias a esta, únicamente
tendrán acceso a los recursos del sistema necesarios y el manejo a fallos debe
tratarse de manera que no afecte nuestro sistema central.

Arquitectura Microservicios:

Este patrón de arquitectura se orienta a la descomposición de los módulos de una

aplicación en servicios independientes de ahí su nombre, al ser una arquitectura
orientada al desacoplamiento nos permite características muy interesantes como lo
estamos pensando, la escalabilidad, el manejo a fallos, el desarrollo independiente
de cada servicio y su mantenimiento son grandes ventajas que encontramos en esta
arquitectura.Es importante mencionar que cada servicio tendra una arquitectura
independientes que se adapte a la función que va a desarrollar.

Los servicios suelen estar distribuidos en diferentes contenedores en Docker, cada

módulo manejara su base de datos independiente para no crear dependencias entre
servicios con lo cual el sistema será tolerante a fallos, un servicio que presente un
error no tendrá que implicar que el sistema falle de igual manera y el tratamiento
correspondiente se hará de manera independiente.
Ventajas:

● Escala fácilmente de una manera altamente eficiente.

● No tiene un único punto de falla.
● Se retira o se reescribe sin comprometer la integridad de toda la
aplicación.
● Está escrito en muchos idiomas y marcos para adaptarse a los
requisitos de cada servicio.
● Cada microservicio se puede desplegar utilizando una plataforma
tecnológica diferente.
● Es simple y discreto.
● Satisface fácilmente los requisitos para los entornos modernos de
PaaS (plataforma como servicio) y SaaS (software como servicio).
● La arquitectura basada en Microservicios favorece la estrategia de
pruebas por niveles.

Arquitectura basada en eventos:

Esta arquitectura se basa en un sistema centrado en la captura, la

comunicación, el procesamiento y la permanencia de los eventos
son la estructura central de la solución. Esto difiere del modelo
tradicional basado en solicitudes.

Una vez definimos la arquitectura procedemos a describir los componentes, primero

tendremos los generadores, estos son componentes que nos van a disparar un
evento ante alguna acción del usuario, lo siguiente a definir son los mensajes, estos
contienen toda la información necesaria del evento para ser compartido con el
componente de mensajería, será el módulo de la aplicación que reciba la
información, la procese de serlo necesario y envíe la información a partes que lo
necesiten, esta información es compartida mediante canales y los que la reciben se
denominará como receptores. generadores, receptores
Canales se implementan en 2 manera,

Patron de publicador

Colas de mensajería

Por último tenemos los componentes procesadores o consumidores, tendrán una

única tarea relacionada con el negocio, tienen que estar desacoplados de la
aplicación ya que solo reciben la información del receptor pero no saben de donde
se generan y su información.

Ya habiendo explicado todos los componentes que hacen parte de la arquitectura

basada en eventos encontramos 2 topologías para su aplicación:

● Topología mediador:

El mediador recibe el evento, lo procesa y coordina los procesadores para

que la salida sea la correcta, es importante resaltar que recibe los eventos de
una cola de eventos.

● Topología Broker:

Recibe un evento y lo pone en el canal apropiado para que el procesador

interesado pueda disponer de él.
Arquitectura MVC (modelo, vista, controlador)

En líneas generales, MVC es una propuesta de arquitectura del software utilizada

para separar el código por sus distintas responsabilidades, manteniendo distintas
capas que se encargan de hacer una tarea muy concreta, lo que ofrece beneficios
diversos.

MVC se usa inicialmente en sistemas donde se requiere el uso de interfaces de

usuario, aunque en la práctica el mismo patrón de arquitectura se puede utilizar
para distintos tipos de aplicaciones. Surge de la necesidad de crear software más
robusto con un ciclo de vida más adecuado, donde se potencie la facilidad de
mantenimiento, reutilización del código y la separación de conceptos.

Por qué MVC

La rama de la ingeniería del software se preocupa por crear procesos que aseguren
calidad en los programas que se realizan y esa calidad atiende a diversos
parámetros que son deseables para todo desarrollo, como la estructuración de los
programas o reutilización del código, lo que debe influir positivamente en la facilidad
de desarrollo y el mantenimiento.

Los ingenieros del software se dedican a estudiar de qué manera se pueden mejorar
los procesos de creación de software y una de las soluciones a las que han llegado
es la arquitectura basada en capas que separan el código en función de sus
responsabilidades o conceptos. Por tanto, cuando estudiamos MVC lo primero que
tenemos que saber es que está ahí para ayudarnos a crear aplicaciones con
mayor calidad.

Quizás, para que a todos nos queden claras las ventajas del MVC podamos echar
mano de unos cuantos ejemplos:

1. Aunque no tenga nada que ver, comencemos con algo tan sencillo como son
el HTML y las CSS. Al principio, en el HTML se mezclaba tanto el contenido
como la presentación. Es decir, en el propio HTML tenemos etiquetas como
"font" que sirven para definir las características de una fuente, o atributos
como "bgcolor" que definen el color de un fondo. El resultado es que tanto el
contenido como la presentación estaban juntos y si algún día pretendíamos
cambiar la forma con la que se mostraba una página, estábamos obligados a
cambiar cada uno de los archivos HTML que componen una web, tocando
todas y cada una de las etiquetas que hay en el documento. Con el tiempo se
observó que eso no era práctico y se creó el lenguaje CSS, en el que se
separó la responsabilidad de aplicar el formato de una web.
2. Al escribir programas en lenguajes como PHP, cualquiera de nosotros
comienza mezclando tanto el código PHP como el código HTML (e incluso el
 Javascript) en el mismo archivo. Esto produce lo que se denomina el "Código
Espagueti". Si algún día pretendemos cambiar el modo en cómo queremos
que se muestre el contenido, estamos obligados a repasar todas y cada una
de las páginas que tiene nuestro proyecto. Sería mucho más útil que el HTML
estuviera separado del PHP.
3. Si queremos que en un equipo intervengan perfiles distintos de profesionales
y trabajen de manera autónoma, como diseñadores o programadores, ambos
tienen que tocar los mismos archivos y el diseñador se tiene necesariamente
que relacionar con mucho código en un lenguaje de programación que puede
no serle familiar, siendo que a éste quizás solo le interesan los bloques donde
hay HTML. De nuevo, sería mucho más fácil la separación del código.
4. Durante la manipulación de datos en una aplicación es posible que estemos
accediendo a los mismos datos en lugares distintos. Por ejemplo, podemos
acceder a los datos de un artículo desde la página donde se muestra éste, la
página donde se listan los artículos de un manual o la página de backend
donde se administran los artículos de un sitio web. Si un día cambiamos los
datos de los artículos (alteramos la tabla para añadir nuevos campos o
cambiar los existentes porque las necesidades de nuestros artículos varían),
estamos obligados a cambiar, página a página, todos los lugares donde se
consumían datos de los artículos. Además, si tenemos el código de acceso a
datos disperso por decenas de lugares, es posible que estemos repitiendo las
mismas sentencias de acceso a esos datos y por tanto no estamos
reutilizando código.

Quizás te hayas visto en alguna de esas situaciones en el pasado. Son solo son
simples ejemplos, habiendo decenas de casos similares en los que resultaría útil
aplicar una arquitectura como el MVC, con la que nos obliguemos a separar nuestro
código atendiendo a sus responsabilidades.

Ahora que ya podemos tener una idea de las ventajas que nos puede aportar el
MVC, analicemos las diversas partes o conceptos en los que debemos separar el
código de nuestras aplicaciones.

Modelos
Es la capa donde se trabaja con los datos, por tanto contendrá mecanismos para
acceder a la información y también para actualizar su estado. Los datos los
tendremos habitualmente en una base de datos, por lo que en los modelos
tendremos todas las funciones que accederán a las tablas y harán los
correspondientes selects, updates, inserts, etc.

No obstante, cabe mencionar que cuando se trabaja con MCV lo habitual también
es utilizar otras librerías como PDO o algún ORM como Doctrine, que nos permiten
trabajar con abstracción de bases de datos y persistencia en objetos. Por ello, en
vez de usar directamente sentencias SQL, que suelen depender del motor de base
de datos con el que se esté trabajando, se utiliza un dialecto de acceso a datos
basado en clases y objetos.

Vistas
Las vistas, como su nombre nos hace entender, contienen el código de nuestra
aplicación que va a producir la visualización de las interfaces de usuario, o sea, el
código que nos permitirá renderizar los estados de nuestra aplicación en HTML. En
las vistas nada más tenemos los códigos HTML y PHP que nos permite mostrar la
salida.

En la vista generalmente trabajamos con los datos, sin embargo, no se realiza un

acceso directo a éstos. Las vistas requerirán los datos a los modelos y ellas se
generará la salida, tal como nuestra aplicación requiera.

Controladores
Contiene el código necesario para responder a las acciones que se solicitan en la
aplicación, como visualizar un elemento, realizar una compra, una búsqueda de
información, etc.

En realidad es una capa que sirve de enlace entre las vistas y los modelos,
respondiendo a los mecanismos que puedan requerirse para implementar las
necesidades de nuestra aplicación. Sin embargo, su responsabilidad no es
manipular directamente datos, ni mostrar ningún tipo de salida, sino servir de enlace
entre los modelos y las vistas para implementar las diversas necesidades del
desarrollo.

Arquitectura Blackboard

El patrón Blackboard es un modelo arquitectónico de software habitualmente

utilizado en sistemas expertos, multiagente y basados en el conocimiento.
Ventajas
● Posibilita la integración de agentes
● Útil cuando el flujo de control del algoritmo es enrevesado

Inconvenientes
● No se garantiza una buena solución
● Alto esfuerzo en desarrollo

Ejemplo.Hearsay II

El sistema Hearsay II fue desarrollado durante el programa de investigación

llevado a cabo por DARPA durante 5 años. Representa una solución específica al
problema de comprensión del discurso y un marco general para coordinar procesos
independientes para lograr un comportamiento cooperativo de resolución de
problemas ya que como problema computacional, la comprensión del habla refleja
una gran cantidad de problemas intrínsecamente interesantes.

Hearsay II usa el patrón pizarra como patrón arquitectónico, que es un modelo

arquitectónico habitualmente utilizado en sistemas expertos, sistemas multiagente
y, en general, sistemas basados en el conocimiento.

Arquitectura Cliente/Servidor

La arquitectura Cliente - Servidor, el cual es un modelo de una aplicación distribuida

en el cual se basa en dos actores: Uno con rol de proveedor de recursos y otro con
rol consultor sobre los recursos. Esto se ha visto en detalle teóricamente y se haría
un ejemplo práctico de cómo se implementa utilizando como lenguaje Python v2.7
utilizando la librería socket. A continuaci´on se le invita a continuar la lectura del
informe.

Como se anticipó anteriormente, dos actores son los fundamentales. El Cliente y el

Servidor.

• Cliente: Programa ejecutable que participa activamente en el establecimiento de

las conexiones. Envía una petición al servidor y se queda esperando por una
respuesta. Su tiempo de vida es finito una vez que son servidas sus solicitudes,
termina el trabajo.

• Servidor: Es un programa que ofrece un servicio que se puede obtener en una red.
Acepta la petición desde la red, realiza el servicio y devuelve el resultado al
solicitante. Al ser posible implantarlo como aplicaciones de programas, puede
ejecutarse en cualquier sistema donde exista TCP/IP y junto con otros programas de
aplicaci´on. El servidor comienza su ejecución antes de comenzar la interacción con
el cliente.