UNIVERSIDAD PRIVADA DOMINGO SAVIO

Materia: SISTEMAS DE INFORMACIÓN III

Tema 2 Arquitectura de software

Docente: Ing. Aida Ramallo Vega

Concepto de Arquitectura Software

➢ La Arquitecturas del Producto Software es una

personalización (derivación) de una arquitectura software
para un producto determinado
➢ Se basa en la personalización de partes variables
(“software variability”) y el empleo de partes comunes
reutilizables
➢ La arquitectura de un producto no se construye
generalmente desde cero
➢ Refleja las características del producto concreto
Principios de Diseño Software

➢ Separación de responsabilidades (“separation of concerns”):

Evitar solapamientos de funcionalidad
➢ Hacer explícita la comunicación entre niveles
➢ Realizar abstracciones para diseñar niveles con bajo grado de
acoplamiento (“loose coupling”)
➢ Modularizar el diseño
➢ Descomponer en subsistemas y módulos
➢ Las arquitecturas se rigen por un conjunto de principios de
diseño software que no se deben violar
Principios de Diseño Software

Cohesion y Acoplamiento son principios de diseño básico en

todo sistema software

Acoplamiento (“Coupling”): Dependencias entre bloques o

módulos de una arquitectura.

Cohesión (“Cohesion”): Dependencias entre variables y métodos

dentro de un componente o módulo.
2.2 Descomposición Modular o Modularización

es el proceso de descomposición de un sistema en un conjunto de

elementos con un índice bajo acoplamiento (independientes) y alto
índice de cohesión (con significado propio).
Consiste en descomponer el problema a resolver en módulos o tareas
más simples. Cada tarea representa una actividad completa y se
codifica de manera independiente. Facilita el diseño descendente del
problema, centrándonos cada vez en la resolución de subproblemas
de magnitud inferior.
A la resolución de cada uno de estos subproblemas de complejidad inferior
se denomina refinamiento por pasos. Los módulos pueden ser planificados,
codificados, comprobados y depurados independientemente, y a
continuación se combinan uno a uno con otros módulos.

El diseño modular propone dividir el sistema en partes diferenciadas y

definir sus interfaces.

Ventajas
•Claridad
•Reducción de costos
•Reutilización
Se siguen los siguientes pasos para poder realizar la descomposición
modular:

•Identificar los módulos

•Describir cada módulo
•Describir las relaciones entre módulos
Una descomposición modular debe poseer ciertas cualidades mínimas para
que se pueda considerar suficiente validad.

1.Independencia funcional
2.Acoplamiento
3.Cohesión
4.Comprensibilidad
5.Adaptabilidad
2.3 Cliente-servidor
2.4 Arquitectura de tres niveles.
La arquitectura de tres niveles es una arquitectura de software de
aplicación bien establecida que separa las aplicaciones en tres niveles de
informática lógica y física: el nivel de presentación o la interfaz de usuario,
el nivel de aplicación o donde se procesan los datos, y el nivel de datos
donde se almacenan y gestionan los datos asociados con la aplicación.

El beneficio principal de la arquitectura de tres niveles es que debido a

que cada nivel se ejecuta en su propia infraestructura, cada nivel puede
ser desarrollado simultáneamente por un equipo de desarrolladores
distinto y se puede actualizar o escalar según sea necesario sin que afecte
a los demás niveles.
Nivel de presentación

El nivel de presentación es la interfaz de usuario y de comunicación de

la aplicación, donde el usuario final interactúa con la aplicación. Su
objetivo principal es mostrar información al usuario y recopilar datos
de este. Este primer nivel se puede ejecutar en un navegador web
como una aplicación de desktop o una interfaz gráfica de usuario
(GUI). Los niveles de presentación web se suelen desarrollar utilizando
HTML, CSS y JavaScript. Las aplicaciones de desktop se pueden escribir
en una variedad de lenguajes, dependiendo de la plataforma.
Nivel de aplicación
Nivel de aplicación

El nivel de aplicación, también conocido como el nivel lógico o medio,

es el núcleo de la aplicación. En este nivel, se procesa la información
recopilada en el nivel de presentación, a veces con otra información en
el nivel de datos, mediante la lógica empresarial; un conjunto
específico de reglas empresariales. El nivel de aplicación también
puede añadir, suprimir o modificar datos en el nivel de datos.
El nivel de aplicación normalmente se desarrolla utilizando Python,
Java, Perl, PHP o Ruby, y se comunica con el nivel de datos mediante
llamadas a las API.
Nivel de datos
El nivel de datos, a veces denominado nivel de base de datos, nivel de
acceso a datos o backend, es donde se almacena y gestiona la
información procesada por la aplicación. Puede ser un sistema de
gestión de base de datos relacional como PostgreSQL, MySQL,
MariaDB, Oracle, DB2, Informix o Microsoft SQL Server, o en un servidor
de bases de datos NoSQL como Cassandra, CouchDB o MongoDB.
En una aplicación de tres niveles, toda la comunicación pasa por el nivel
de aplicación. Los niveles de presentación y de datos no pueden
comunicarse directamente entre sí.
 2.5 Modelo Vista Controlador.
El MVC o Modelo-Vista-Controlador es un patrón de arquitectura de
software que, utilizando 3 componentes (Vistas, Models y Controladores)
separa la lógica de la aplicación de la lógica de la vista en una aplicación.
Es una arquitectura importante puesto que se utiliza tanto en
componentes gráficos básicos hasta sistemas empresariales; la mayoría de
los frameworks modernos utilizan MVC (o alguna adaptación del MVC)
para la arquitectura, entre ellos podemos mencionar a Ruby on
Rails, Django, AngularJS y muchos otros más. En este pequeño artículo
intentamos introducirte a los conceptos del MVC.
Modelo
Se encarga de los datos, generalmente (pero no obligatoriamente)
consultando la base de datos. Actualizaciones, consultas, búsquedas,
etc. todo eso va aquí, en el modelo.
Controlador
Se encarga de... controlar, recibe las órdenes del usuario y se encarga
de solicitar los datos al modelo y de comunicárselos a la vista.
Vistas
Son la representación visual de los datos, todo lo que tenga que ver
con la interfaz gráfica va aquí. Ni el modelo ni el controlador se
preocupan de cómo se verán los datos, esa responsabilidad es
únicamente de la vista.
 2.6 Orientada a servicios
La arquitectura orientada a los servicios (SOA) es un tipo de diseño de
software que permite reutilizar sus elementos gracias a las interfaces de
servicios que se comunican a través de una red con un lenguaje común.
Un servicio es una unidad autónoma de una o más funciones del
software diseñada para realizar una tarea específica, como recuperar
cierta información o ejecutar una operación. Contiene las integraciones
de datos y código que se necesitan para llevar a cabo una función
empresarial completa y diferenciada. Se puede acceder a él de forma
remota e interactuar con él o actualizarlo de manera independiente.

En otras palabras, la SOA integra los elementos del software que se

implementan y se mantienen por separado, y permite que se
comuniquen entre sí y trabajen en conjunto para formar aplicaciones de
software en distintos sistemas.
¿Cómo funciona la arquitectura orientada a los servicios?

Antes de que se empezara a utilizar la SOA a fines de los

noventa, era muy difícil conectar una aplicación con los
servicios alojados en otro sistema, y se necesitaba
una integración profunda de punto a punto (conectividad,
enrutamiento, traducción de los modelos de datos, etc.). Luego,
los desarrolladores debían repetir el proceso para cada
proyecto nuevo. Este modelo se conocía como "monolítico", ya
que el código para toda la aplicación formaba parte de una
sola implementación. Si algo no funcionaba correctamente,
debía darla de baja por completo hasta que se solucionaran los
problemas y luego volver a implementarla como una versión
nueva.
Dado que la SOA expone los servicios utilizando protocolos
estándar de red para enviar solicitudes o acceder a los datos
(p. ej., SOAP, JSON, ActiveMQ o Apache Thrift), no es necesario que
los desarrolladores realicen las integraciones desde cero. De hecho,
pueden utilizar los patrones llamados buses de servicios
empresariales (ESB) para integrar un elemento centralizado y los
sistemas de backend, y ponerlos a disposición de todos como
interfaces de servicios. Asimismo, pueden reutilizar las funciones
actuales en vez de volver a crearlas.
En este tipo de arquitectura, los servicios se comunican por medio
de un sistema "sin conexión directa". Se trata de un método para
interconectar los elementos en un sistema o una red, de modo que
puedan transmitir información o coordinar un proceso empresarial,
mientras se reduce la dependencia entre ellos. En consecuencia,
esto da origen a una nueva aplicación.
Funciones de la SOA
Los elementos esenciales de la arquitectura orientada a los
servicios consisten en tres funciones.

1.Proveedor de servicios
2.Se encarga de crear servicios web, ofrecerlos a un registro de
servicios disponibles y gestionar sus condiciones de uso.

3.Agente o registro de servicios

4.Se encarga de brindar información acerca del servicio a quien lo
solicite, y puede ser público o privado.

5.Usuario del servicio o persona que lo solicita

6.Buscará un servicio en el registro o por medio del agente, y se
conectará con el proveedor para recibirlo.
 2.7 Arquitectura de micro servicios

Modernizar las aplicaciones en el mundo actual a menudo conlleva migrar a aplicaciones

nativas de la nube creadas como microservicios. A continuación, se implementan
mediante tecnologías de contenedores como Docker y Kubernetes. Netflix y Atlassian lo
hicieron, así como infinidad de otras organizaciones. El motivo: una arquitectura de
microservicios mejora la escalabilidad, la velocidad del desarrollo y la iteración de
servicios.
Una arquitectura de microservicios divide una aplicación en una serie de servicios
implementables de forma independiente que se comunican a través de API. Este
enfoque permite implementar y escalar cada servicio individual de forma independiente,
así como la entrega rápida y frecuente de aplicaciones grandes y complejas. A diferencia
de una aplicación monolítica, una arquitectura de microservicios permite a los equipos
implementar nuevas funciones y hacer cambios más rápido, sin tener que volver a
escribir una gran parte del código existente.
Estas son algunas de las características fundamentales de las arquitecturas de
microservicios:
2.8 Dirigida por eventos.
La arquitectura basada en eventos utiliza eventos para desencadenar y establecer
comunicación entre servicios desacoplados, y es común en las aplicaciones
modernas creadas con microservicios. Un evento es un cambio de estado, o una
actualización, como un elemento que se coloca en un carro de compras de un
sitio web de comercio electrónico. Los eventos pueden llevar el estado (el
elemento comprado, su precio y una dirección de entrega) o pueden ser
identificadores (una notificación de que se envió una orden).

Las arquitecturas impulsadas por eventos tienen tres componentes clave:

procedimientos de eventos, enrutadores de eventos y consumidores de
eventos. Un productor publica un evento para el enrutador, que filtra y envía los
eventos a los consumidores. Los servicios del productor y los servicios del
consumidor se desacoplan, lo que les permite escalarse, actualizarse e
implementarse de manera independiente.
Cómo funciona: arquitectura de ejemplo
Este es un ejemplo de arquitectura basada en eventos para un sitio de comercio electrónico.
Esta arquitectura permite que el sitio reaccione a los cambios procedentes de diversas fuentes
durante los momentos de mayor demanda, sin que se bloquee la aplicación ni se sobre a
provisionen recursos.
2.9 Máquina virtual (Virtual Machines)
Una máquina virtual (VM) es un entorno virtual que funciona como sistema
informático virtual con su propia CPU, memoria, interfaz de red y
almacenamiento, pero se crea en un sistema de hardware físico, ya sea en las
instalaciones o no. El sistema de software se llama hipervisor, y se encarga de
separar los recursos de la máquina del sistema de hardware e implementarlos
adecuadamente para que la VM pueda utilizarlos.
Las máquinas físicas equipadas con un hipervisor, como la máquina virtual
basada en el kernel (KVM), se denominan máquinas host, computadoras host,
sistemas operativos host o simplemente hosts.Las diversas máquinas virtuales
que usan sus recursos son máquinas guest, computadoras guest, sistemas
operativos guest, o simplemente guests. El hipervisor utiliza los recursos
informáticos, como la CPU, la memoria y el almacenamiento, como un conjunto
de medios que pueden redistribuirse fácilmente entre los guests actuales o en
las máquinas virtuales nuevas.
Investigue lo siguiente:

Tipos de arquitectura de Patrones de arquitectura de software

software
1. Sistemas de Software microkernel
Arquitectura Spaghetti 2. Patrón de arquitectura microservicios
Arquitectura REST 3. Patrón de arquitectura Event-based
Arquitectura en capas pattern
Arquitectura hexagonal 4. Patrón CQRS
5. Patrón de arquitectura basado en el
espacio

Investigue el red Hat virtualizacion