UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

CURSO:

Teleinformática

DOCENTE:

Suarez Rebaza Camilo Ernesto

CICLO:

V CICLO

INTEGRANTES:

● Geronimo Dionicio Percy Olivarez (coordinador)

● Mecola Bernedo Jesus Christopher
● Rebaza Arteaga Franpresly Annjel

TRUJILLO – PERÚ

2021
 Índice

1.) Principios de diseño Solid.

2.) Patrones de Diseño vs Patrones de Arquitectura.

3.) Arquitectura Restfull.

4.) Arquitectura Octogonal de Software.

5.) Arquitectura monolítica vs arquitectura microservicios.

 1. Principios de Diseño SOLID
 
SOLID es un acrónimo acuñado por Robert C.Martin en el cual se representan los cinco
principios básicos de la programación orientada a objetos. La intención de seguir estos
principios es eliminar malos diseños, evitar la refactorización y construir un código más
eficiente y fácil de mantener. 
Los cinco principios de SOLID para el diseño de aplicaciones de software son: 

 S – Single Responsability Principle (SRP) 

 O – Open/Closed Principle (OCP) 
 L – Liskov Substitution Principle (LSP) 
 I – Interface Segregation Principle (ISP) 
 D – Dependency Inversion Principle (DIP) 
 
Estos principios son la base de mucha literatura que encontrarás en torno al
desarrollo de software: muchas arquitecturas se basan en ellos para proveer
flexibilidad, el testing necesita confiar en ellos para poder validar partes de código
de forma independiente, y los procesos de refactorización serán mucho más
sencillos si se cumplen estas reglas. Así que es muy conveniente que asimiles bien
estos conceptos.
 
¿Qué beneficios aporta usar los Principios Solid?
 
Las ventajas de utilizar los Principios SOLID son innumerables, ya que nos aportan

todas esas características que siempre queremos ver en un software de calidad.

En cada uno de los principios nos iremos centrando en qué aportan

específicamente, pero es interesante hacer un resumen general de lo que

conseguiremos con ellos:

Software más flexible: mejoran la cohesion disminuyendo el acoplamiento.

Los conceptos de cohesión y acoplamiento merecen un artículo a parte, pero a

grandes rasgos lo que buscamos de un buen código es que sus clases puedan

trabajar de forma independiente y que el cambio de uno afecte lo menos posible al

resto.
Obviamente cuando dos clases se relacionan entre sí para trabajar juntas (y esto

tiene que ocurrir sí o sí), va a existir un acoplamiento entre ellas.

Pero existen distintos niveles de acoplamiento, y gracias a algunos de los Principios

SOLID, podemos relajar esas dependencias y hacerlas mucho más flexibles a

cambios.

Te hacen entender mejor la arquitectura:

Siempre que hablo de arquitecturas, noto que hay una barrera importante para

entender cómo aplicarlas y qué beneficios aportan.

Esto es porque primero hace falta entender los principios sobre los que se

sustentan, y los principios SOLID son muy importantes para ello.

Simplifican la creación de tests: 

Todo esto está muy relacionado con los puntos anteriores: si tienes tu código

desacoplado y una buena arquitectura, los tests van a ser mucho más sencillos.

En un vídeo anterior ya comentaba los 7 errores que solemos cometer al escribir

tests, y mucho del tema va por aquí.

Al final piensa que todo es como una cadena: si aplicas bien los principios, organizar

mejor tu código. Esto te permite definir una arquitectura que hará que los tests sean

más sencillos.

Podría decirse por tanto que los Principios SOLID son parte de la base de un código

de calidad.
 

2. Patrones de Diseño y Patrones de Arquitectura

Cuando iniciamos hablar de patrones, hay varios términos que nos alejan de

su entendimiento, por ejemplo, se habla de patrones de arquitectura de

software, de estilos de arquitecturas de software, de patrones de diseño, pero

¿Qué diferencias hay?, ¿Puedo utilizar esos términos de forma indistinta?, ¿En

que momentos se se pueden aplicar?, me gustaría compartir pequeños

matices que los hacen diferentes.

  
 
¿Que es un patrón?
Es una solución general y reutilizable para un problema común de acuerdo a un
contexto dado el cual puede aplicarse a cualquier dominio del software y se hacen
presentes en determinadas fases del ciclo de vida del software: análisis/diseño,
construcción/desarrollo.

Un patrón es aplicable según el tipo de problema a resolver.

De acuerdo a la imagen anterior podemos identificar diferencias entre los términos Patrón

de Arquitectura de Software y Patrones de diseño, pero que hay acerca de los

estilos(style) de Arquitectura de Software, ¿Es lo mismo que un patrón de Arquitectura de

Software? ¿Existe alguna diferencia?, la respuesta directa es: Depende a quién se lo

preguntes, algunos Arquitectos mencionan que se pueden utilizar de forma indistintas,

otros, comentan que hay pequeños matices, Wikipedia menciona que si hay pequeñas

diferencias, Microsoft menciona en un artículo del 2009 que los términos se pueden

manejar como igual, también hacen una analogía con la Arquitectura tradicional de

Edificios.

Hablando de la Arquitectura de Software podríamos concluir que el patrón es algo que es

aplicable de forma general y los estilos va a lo particular de acuerdo a su patrón, los

cuales se complementan, por ejemplo: Para resolver un problema que requiere interacción

con eventos podemos utilizar el patrón Event Drive Architecture (EDA) bajo un estilo de

Arquitectura Publish and Subscribe o el estilo Pipe and Filter.

Patrones de Arquitectura de Software:

Son aplicables a la fase de diseño o análisis en el ciclo de vida del software y su

principal objetivo es dar solución a problemas comunes que se presentan en

Arquitectura de Software, por mencionar algunos patrones:

 Arquitectura de Capas (Layered Architecture).

 Arquitectura Orientada a Eventos (Event-Driven Architecture)

 Arquitectura de Microservicios. (Microservice Architecture)

 Arquitectura Space-Based. (Space-Based Architecture)

 Arquitectura MicroKernel. (Microkernel Architecture)

 Patrones de Diseño:
Este tipo de Patrones son aplicables para la fase de construcción o desarrollo en el

ciclo de vida del software e indica la forma de estructurar tu código, de organización

e interacción entre objetos, clases, instancias, relaciones, existen cuatro grandes

grupos:

Creacionales (Creational)

Corresponden aquellos patrones que proponen la mejor manera para la creación de

instancias como:

 Abstract Factory.

 Builder.

 Factory Method.

 Prototype.

 Singleton.
  Object-Pool.

 Model View and Controller (MVC).

Estructurales (Structural)

Se enfocan en resolver problemas de composición (agregación) de clases y objetos.

 Adapter.

 Bridge.

 Composite.

 Decorator.

 Facade.

 Proxy.

 Flyweight.

 Module.

De Comportamiento

Ofrecen soluciones para la interacción y responsabilidad entre clases y objetos.

 Chain of Responsability.

 Command.

 Interpreter.

 Iterator.
  Mediator.

 Memento.

 Observer.

 State.

 Strategy.

 Template Method.

 Visitor.

Conclusiones:
Ahora podemos concluir que entre los Patrones de Arquitectura de Software y los

Patrones de Diseño hay un diferencias clara, el primero se enfoca en la fase de

diseño y nos proporciona elementos para resolver problemas a nivel del diseño de la

Arquitectura de nuestro sistema y el segundo nos proporciona elementos para

resolver problemas a nivel de nuestro código, como se organizarán, se crearán y se

comportarán las clases, los objetos, las instancias en el sistema.

          Arquitectura RESTFul

¿Qué es un servicio web?

Un servicio Web es un sistema de software diseñado para admitir la interacción

interoperable de máquina a máquina a través de una red. Tiene una interfaz descrita en un

formato de proceso de máquina (específicamente WSDL). Otros sistemas interactúan con el

servicio web en una forma prescrita por su descripción utilizando mensajes SOAP,
normalmente transmitidos utilizando HTTP con una serialización XML junto con otros

estándares relacionados con la Web.

Podemos identificar dos clases principales de servicios Web:

 Servicios Web que cumplen con REST, en los cuales el propósito principal del servicio es manipular

representaciones XML de recursos web utilizando un conjunto uniforme de operaciones «sin estado»

 Servicios Web arbitrarios, en los que el servicio puede exponer un conjunto arbitrario de operaciones.

 ¿Qué es un rest?

 El objetivo principal de cualquier sistema distribuido es facilitar el acceso a

recursos remotos. REST se diseñó pensando en ser simple, con ello se lograría

una rápida adopción del usuario y un desarrollo rápido.

Servicios Web RESTful

Los dos conceptos clave son necesarios ya que un servicio Web RESTful es aquél
servicio web que está basado en la arquitectura REST. Los servicios Web RESTful se
basan en recursos. Un recurso es una entidad, la cual se almacena principalmente en un
servidor y el cliente solicita el recurso utilizando servicios Web RESTful.

Características principales de un servicio Web RESTful

 Tiene cinco operaciones típicas: listar, crear, leer, actualizar y borrar

 Cada operación requiere de dos cosas: El método URI y HTTP

 El URI es un sustantivo que contiene el nombre del recurso

 El método HTTP es un verbo.









 Arquitectura Ortogonal de Software

 La ortogonalidad es una propiedad de las unidades centrales de procesamiento. Se dice

que un conjunto de instrucciones es ortogonal cuando se puede utilizar cualquier modo

de direccionamiento en cualquier instrucción. La búsqueda de la ortogonalidad hace que

el diseño de la unidad central de procesamiento sea más complejo pero aporta una

mayor facilidad de programación.

 Se refiere a la capacidad de combinar varias características de un lenguaje de

programación en todas las combinaciones posibles, de manera que todas ellas

tengan significado. Por ejemplo, suponga que un lenguaje dispone de una expresión

que puede producir un valor y también dispone de un enunciado condicional que

evalúa una expresión para obtener un valor de verdadero o falso. Estas dos

características del lenguaje, la expresión y el enunciado condicional, son ortogonales

si se puede usar (y evaluar) cualquier expresión dentro del enunciado condicional.

  Cuando las características de un lenguaje son ortogonales, entonces es más fácil

aprender el lenguaje y escribir los programas porque hay menos excepciones y

casos especiales que recordar. El aspecto negativo de la ortogonalidad es que un

programa suele compilar sin errores a pesar de contener una combinación de

características que son lógicamente incoherentes o cuya ejecución es en extremo

ineficiente. A causa de estas cualidades negativas, la ortogonalidad como atributo

de un diseño de lenguaje es todavía motivo de controversia, pues a ciertas personas

les gusta y a otras no.

 La no generalidad de la comparación de igualdad puede ser vista como una no

ortogonalidad ya que la aplicación de “=” depende del tipo de los valores a comparar.

Otros ejemplos adicionales de pérdida de ortogonalidad:

Las funciones Pascal pueden tomar solo valores escalares o apuntadores. En C valores de

todo tipo, excepto de tipo arreglo, pueden ser retomados desde una función. En Ada esta no-

ortogonalidad se elimina. En Pascal los tipos ficheros tienen un estatus especial que causa

un número de no-ortogonalidades, por ejemplo, los ficheros no pueden ser pasados por

valor y está prohibida la asignación a variables fichero. En muchos otros lenguajes los

ficheros forman parte de bibliotecas (dependientes del sistema) en vez de a la definición del

lenguaje evitando con ello tales no-ortogonalidades. En Modula 2 las cadenas pueden

asignarse a variables de cadena de mayor longitud, pero no viceversa, este es el único caso

en Modula 2 donde la asignación trabaja para objetos de igual medida. En C hay una no

ortogonalidad en el traspaso de parámetros: C pasa todos los parámetros por valor excepto

los arreglos que los pasa por referencia. Aquí se ve mejor la no ortogonalidad. La
ortogonalidad fue la meta principal del ALGOL-68, que sigue siendo el mejor ejemplo de

lenguaje donde sus constructores pueden ser combinados en todas maneras significativas.

Arquitectura Monolítica vs Arquitectura de Microservicios

Arquitectura monolítica 

Las aplicaciones monolíticas o sistemas monolíticos, tienen como característica el uso de

una base de código única para sus servicios o funcionalidades.

Aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no es la

mejor opción, en el caso de que se tengan aspiraciones de crecimiento complejas, más

usuarios, más desarrolladores…

Además, debes tener en cuenta que un gran inconveniente que caracteriza a las

aplicaciones monolíticas, es que en el momento que se quiera realizar un nuevo despliegue,

se debería relanzar todo el sistema de nuevo.

Otra de las dificultades que plantean los sistemas monolíticos, son la imposibilidad de

trabajar en varios ambientes al mismo tiempo (por tiempos de carga), lo que dificulta

enormemente el trabajo de los arquitectos o desarrolladores de software.

Microservices

Frente a estas aplicaciones monolíticas, surgen los microservicios. Una opción muy efectiva

que está cautivando a muchos desarrolladores de software, ¡y no es para menos!

“La arquitectura de microservicios tiene como objetivo aislar los distintos componentes de

una aplicación, con el fin de que cada uno sea una aplicación por sí misma.”

Podríamos considerar que los microservicios son una evolución del Service Oriented

Architecture o SOA, cuya función se basa en desarrollar servicios independientes para el

negocio, estando cada uno de estos asociados o unidos a una misma aplicación.

A diferencia de SOA, los microservicios permiten que un componente específico del mismo,

evolucione más allá de sus capacidades, ya sea dividiéndolo en elementos más pequeños o

dotándola de mayores recursos.

 
 

Bibliografía:

- https://www.viewnext.com/arquitectura-de-microservicios-vs-arquitectura-
monolitica/#:~:text=De%20forma%20muy%20resumida%2C%20puede,sujetos
%20en%20un%20mismo%20programa.&text=En%20esta%20arquitectura%2C
%20cada%20proceso%20o%20microservicio%20es%20un%20elemento
%20independiente.

- https://decidesoluciones.es/arquitectura-de-microservicios/ .

https://blog.softtek.com/es/eres-un-programador-pragm%C3%A1tico-ii#:~:text=En
%20un%20software%20ortogonal%20las,f%C3%A1cil%20de%20testear%20y
%20ampliar.&text=Cuando%20un%20software%20no%20es,dif%C3%ADcil%20de
%20cambiar%20y%20controlar.

https://gausswebapp.com/arquitectura-rest.html#:~:text=REST%20es%20una
%20arquitectura%20de,utilizada%20en%20cualquier%20cliente%20HTTP.&text=Es
%20decir%2C%20toda%20la%20informaci%C3%B3n,y%20almacenamiento
%20interno%20del%20servidor.
-