UNIVERSIDAD TECNICA PARTICULAR DE LOJA

Nombre: Lourdes Belen Peñafiel Garcia

Foro: Conoce los fundamentos teóricos de la ingeniería y arquitectura de software, que

son útiles para proponer y diseñar una arquitectura.

1.1. En sus propias palabras, ¿Qué es Arquitectura de Software?

La arquitectura de software es el diseño fundamental y la estructura organizativa de un
sistema de software. Define la manera en que los diferentes componentes del sistema
interactúan entre sí y cómo se comunican. Incluye decisiones de alto nivel sobre la
distribución de responsabilidades, la asignación de tareas y la organización de los
elementos de software.
1.2 ¿Existen sistemas o aplicaciones que no posean una arquitectura de software?
Argumente su respuesta.
No, todos los sistemas o aplicaciones de software tienen una arquitectura, aunque esta
puede variar en complejidad y formalidad.
Incluso en el caso de sistemas muy simples o pequeñas aplicaciones, existe una
estructura subyacente que define cómo funcionan los componentes. Aunque esta
arquitectura puede no estar documentada o ser muy rudimentaria, sigue existiendo. Por
ejemplo, una calculadora de escritorio muy básica aún tiene una estructura que organiza
su interfaz gráfica, lógica de cálculos y manejo de eventos.
Sin embargo, la diferencia radica en la calidad y la intencionalidad de la arquitectura.
Los sistemas bien diseñados y de mayor escala requieren una arquitectura
cuidadosamente planificada y documentada para garantizar la escalabilidad, la
mantenibilidad y la adaptabilidad a medida que el sistema evoluciona. En contraste,
aplicaciones más simples o prototipos pueden tener una arquitectura menos formal y
planificada, pero aún así tienen una estructura subyacente que define su funcionamiento.
1.3 Describa al menos 5 estilos arquitectónicos, indique pros y contras y su
aplicabilidad.
1.3.1 Arquitectura Monolítica:
 Pros: Simple de desarrollar y desplegar, adecuada para aplicaciones pequeñas y
menos complejas.
 Contras: Puede volverse difícil de mantener y escalar a medida que la aplicación
crece.
1.3.2 Arquitectura Cliente-Servidor:
 Pros: Permite la distribución de la carga de trabajo entre clientes y servidores,
facilitando la escalabilidad.
 Contras: Mayor complejidad en la configuración y administración de servidores.
1.3.3 Arquitectura de Microservicios:
 Pros: Favorece la escalabilidad, la independencia de desarrollo y despliegue de
servicios individuales.
  Contras: Mayor complejidad en la gestión de la comunicación entre
microservicios.
1.3.4 Arquitectura de Capas (Layered Architecture):
 Pros: Promueve la separación de preocupaciones y facilita la reutilización de
componentes.
 Contras: Puede generar cierta complejidad al gestionar la comunicación entre
capas.
1.3.5 Arquitectura basada en Eventos:
 Pros: Permite la comunicación asincrónica y la escalabilidad basada en eventos.
 Contras: Puede ser más compleja de diseñar y depurar.
1.4 ¿Qué competencias debe tener un buen Arquitecto de Software?
1 Profundo conocimiento técnico en tecnologías y lenguajes relevantes.
2 Habilidades de comunicación y trabajo en equipo para colaborar con
desarrolladores y partes interesadas.
3 Habilidad para analizar y resolver problemas complejos de diseño y arquitectura.
4 Entendimiento de los principios de diseño y patrones arquitectónicos.
5 Capacidad para tomar decisiones estratégicas que afecten a todo el sistema de
software.
2.1 Diagrame la arquitectura de un sistema de micro-servicios y explique sus
componentes y relaciones. Indique un caso de uso de este estilo.
Arquitectura de Microservicios: La arquitectura de microservicios es un enfoque para
diseñar sistemas de software donde una aplicación se compone de pequeños servicios
independientes que se comunican entre sí a través de interfaces bien definidas. Cada
microservicio es una unidad de negocio o funcionalidad que puede ser desarrollada,
desplegada y escalada de forma independiente.
 Figura 1 Diagrama Arquitectonico Micro-Servicio

Lado del cliente

Esta capa, hace referencia frontend la misma que cuenta con los siguientes framework’s
de desarrollo angular para desarrollo web, ionic para el desarrollo de aplicaciones
móviles híbridas , bootstrap y angular material para el diseño de interfaces responsivos
adaptables a los dispositivos inteligentes basados en el estándar html5 y css3 , y, por
último, la integración de openstreetmap como proveedor de mapas en línea.
Lado del servidor Backend
En el lado del servidor, la arquitectura del sistema propuesto está dividida en 4
secciones que se describen a continuación:
 Seguridad Se encarga de gestionar los roles y permisos de acceso a la aplicación. Este
proceso es ejecutado por el sistema en dos pasos: un proceso de registro donde se
identifica al usuario y un proceso de verificación cada vez que el usuario inicia una
nueva sesión en la aplicación otorgándole un token, según los roles asignado se tiene
acceso a los microservicios que son mapeados de acuerdo a perfiles pre establecidos
como: administrador, publicador, transporte, transportista y usuario en general.
El estándar de seguridad utilizado en la aplicación es Open Authorization , que permite
flujos de autorización para las API implementadas en los microservicios.
 Gateway En esta sección de la Arquitectura, se implementa un proceso de puerta de
enlace ente los requerimientos de consumo del cliente y por otra parte el servidor.
Eureka hace el descubrimiento y balanceo de carga de los microservicios de la
aplicación, transformando la petición según lo requerido por el cliente.
 Microservicios En la Tabla 1 se detalla cada uno de los microservicios implementados
en la lógica de negocios mediante el framework Spring Boot, cada uno de estos se
definen independientes entre sí.
 Microservicio Objetivo
Registro Permite a los usuarios realizar el registro
de su información en la plataforma
Autenticación Contiene la información del usuario y
roles, la autenticación en el sistema se
realiza mediante el ingreso de su usuario
y contraseña; Aquí se utiliza la
herramienta Oauth2.0 el cual brinda
token al cliente que permitirá el acceso a
los microservicios según su rol.
Categorías Permite crear un CRUD de las categorías
(rol administrador).
Negocios Permite administrar la información de los
comercios (rol publicador).
Productos Este microservicio permite realizar un
CRUD de los productos de cada negocio
(rol publicador).
Carrito de compras Es uno de los principales del sistema, ya
que es el encargado de la gestión de
pedidos en línea por parte de los
consumidores, notificando así a los
negocios y a las empresas de delivery por
cada solicitud de compra en la plataforma
Entregas Permite la gestión (entregas a domicilio,
asignación de un transporte) por cada
solicitud de compra (rol transporte).
Notificaciones Se encarga de realizar las notificaciones
(notificación de compra, estado del
pedido y promociones) a los usuarios,
este servicio cuenta con una integración
con las API’s de chat-api .

 Acceso a datos
Esta capa se implementó a través del ORM como se muestra en la figura 4, con el
framework hiberbate, que permite la persistencia de los datos en una base de datos
relacional y al mismo tiempo permite emplearla programación orientada a objetos
(POO) en la aplicación.

2.2 Diagrame la arquitectura de un sistema N Capas y explique sus componentes y

relaciones. Indique un caso de uso de este estilo.
Arquitectura N Capas:
La arquitectura N Capas es un estilo arquitectónico que organiza un sistema de software
en múltiples capas o niveles, donde cada capa tiene una responsabilidad específica y se
comunica con las capas adyacentes. Este enfoque facilita la separación de
preocupaciones y la modularidad del sistema.
Componentes y Relaciones:
Presentación (Capa de Interfaz de Usuario):
 Responsabilidad: Interfaz gráfica, interacción con el usuario.
 Componentes: Interfaces de usuario, elementos de diseño, controladores de
eventos.
 Relaciones: Interactúa con la Lógica de Negocio para obtener y mostrar datos en
la interfaz.
Lógica de Negocio (Capa de Aplicación):
 Responsabilidad: Procesamiento de la lógica de negocio y reglas de negocio.
 Componentes: Clases y métodos que implementan la lógica de la aplicación.
 Relaciones: Recibe peticiones de la Capa de Presentación y realiza operaciones
sobre los datos.
Acceso a Datos (Capa de Persistencia):

 Responsabilidad: Acceso y manipulación de datos en la base de datos o

almacenamiento.
 Componentes: Módulos de acceso a la base de datos, consultas SQL u ORM.
 Relaciones: Interactúa con la Lógica de Negocio para proveer o actualizar datos
según las solicitudes.
Base de Datos (Capa de Almacenamiento):
 Responsabilidad: Almacenamiento persistente de datos.
 Componentes: Sistema de gestión de bases de datos (por ejemplo, MySQL,
MongoDB, etc.).
 Relaciones: Utilizado por la Capa de Acceso a Datos para realizar operaciones
de lectura y escritura.
Infraestructura y Redes:
 Responsabilidad: Gestión de aspectos relacionados con la comunicación y la
infraestructura.
 Componentes: Servidores, protocolos de comunicación, servicios de red.
 Relaciones: Facilita la comunicación entre las capas y gestiona la infraestructura
subyacente.
Caso de Uso
Un sistema de gestión de biblioteca como ejemplo de uso de la arquitectura N Capas.
Componentes:
 Presentación: Interfaz de usuario que permite a los usuarios buscar y reservar
libros.
 Lógica de Negocio: Gestiona la lógica de préstamos, devoluciones y reservas de
libros.
 Acceso a Datos: Realiza consultas a la base de datos para obtener información
de libros y usuarios.
 Base de Datos: Almacena la información sobre libros, usuarios y transacciones.
Relaciones:
 La Capa de Presentación muestra la interfaz gráfica y envía solicitudes a la
Lógica de Negocio.
 La Lógica de Negocio procesa las solicitudes, interactúa con la Capa de Acceso
a Datos para obtener información de la Base de Datos y devuelve resultados a la
Presentación.
 La Capa de Acceso a Datos se comunica con la Base de Datos para realizar
operaciones de lectura y escritura.
Este es un ejemplo de cómo se organizaría un sistema de gestión de biblioteca
utilizando una arquitectura N Capas.
REFERENCIAS
1 Bhatti, H. Akram, H. M. Basit, A. U. Khan, and S. M. Raza, “E-commerce trends
during COVID-19 Pandemic,” vol. 13, no. 2, pp. 1449–1452, 2020.
2 L. Periolo et al., “Marketing + internet = e-commerce : oportunidades,” Cuad.
Econ. y Dir. la Empres., vol. 13, no. 16, p. 118, 2013, doi: 10.1016/s1138-
5758(07)70081-6.
3 Familiar and B. Familiar, Microservice Architecture. 2015.
4 R. Marcelo, M. Hinojosa, Í. Omar, M. Pazmiño, H. Patricio, and D. Solís,
“Emprendimiento y marketing durante el aislamiento social por la pandemia
Entrepreneurship and marketing during social isolation due to the pandemic,” pp.
0–1.