UNIVERSIDAD NACIONAL DE UCAYALI

FACULTAD DE INGENIERÍA DE SISTEMAS E INGENIERÍA CIVIL ESCUELA

PROFESIONAL DE INGENIERÍA DE SISTEMAS

ARQUITECTURA INVESTIGACION Y PATRONES DE

DESIÑO

ASIGNATURA: DISEÑO DE SISTEMA

CICLO: VI-B

DOCENTE: ING. MAG. DIANA DIAZ ESTRADA

ALUMNO: PADILLA LESTA, AMERICO DAVID

PUCALLPA – PERÚ
2023
 ARQUITECTURAS CLIENTE/SERVIDOR

Inicialmente los sistemas de BD eran de tipo estrictamente centralizado, en el sentido que se

ejecutaban sobre un único sistema informático, sin necesidad de interaccionar con ningún otro.
Pero el abaratamiento de los ordenadores personales y el desarrollo de sus capacidades, junto
con la implantación de las redes y de Internet, ha hecho evolucionar los sistemas centralizados
hacia arquitecturas de tipo cliente-
servidor o arquitectura en dos niveles. Este sistema de bases de datos posee una
estructura compuesta de dos partes. Están son:

1. El servidor permite llevar a cabo las funciones propias del SGBD, se puede decir
que el servidor es en sí, el SGBD.

2. Un cliente es cada consumidor de recursos de la base de datos.

El software de este tipo de arquitecturas posee varios componentes que se pueden asociar
al cliente o al servidor:

 Software de gestión de datos: normalmente reside en el servidor y lleva a cabo la

gestión de los datos que requieren las aplicaciones.
 Software de interacción con el usuario y presentación: suele residir en el cliente e
implementa las funciones de una interfaz gráfica de usuario.
 Software de desarrollo: suele residir en el cliente y se utiliza para desarrollar
aplicaciones.
 Otros elementos de software que facilitan la conexión cliente-servidor: tanto en el
cliente como en el servidor se instala software de sistemas operativos en red, de
aplicaciones específicas de base de datos, de comunicaciones, etc.
 Ventajas de los sistemas de bases de datos cliente/servidor:
 La distribución los procesos entre el cliente y el servidor evita la disminución de
velocidad de ejecución que ocurre en los procesos de datos centralizados, aunque puede
generar cuellos de botella por la velocidad del tráfico de red.
 Empleo de ordenadores estándar para el servidor y los clientes, en lugar de grandes
equipos.
 Son sistemas escalables y modulares, es decir, se puede aumentar la cantidad de
servicios prestados por los ordenadores y reemplazarlos por equipos nuevos sin que sea
afectado por el cambio de SGBD.
 Disponibilidad de herramientas de desarrollo de calidad: lenguajes de 4
generación orientados a objetos y a procedimientos y entornos gráficos de
desarrollo, herramientas de modelado de datos, etc.
 ARQUITECTURA DE 3 CAPAS

La arquitectura de tres capas es un diseño reciente que introduce una capa intermedia en el
proceso. Cada capa es un proceso separado y bien definido corriendo en plataformas separadas.
En la arquitectura tradicional de tres capas se instala una interfaz de usuario en la computadora
del usuario final (el cliente). La arquitectura asada en Web transforma la interfaz de búsqueda
existente (el explorador de Web), en la interfaz del usuario final.

La arquitectura de las aplicaciones web suelen presentar un esquema de tres niveles

El primer nivel consiste en la capa de presentación que incluye no sólo el navegador, sino
también el servidor web que es el responsable de presentar los datos un formato adecuado.
El segundo nivel está referido habitualmente a algún tipo de programa o script.
Finalmente, el tercer nivel proporciona al segundo los datos necesarios para su ejecución.
Una aplicación Web típica recogerá datos del usuario (primer nivel), los enviará al servidor,
que ejecutará un programa (segundo y tercer nivel) y cuyo resultado será formateado y
presentado al usuario en el navegador (primer nivel otra vez).

Las diferentes capas suelen ser:

Capa 1: Cliente de aplicación: Navegador Web
Capa 2: Servidor de Aplicaciones: Apache, Servidor Tomcat con servlet’s
Capa 3: Servidor de Datos: base de datos, servidor SMTP…

Ventajas de la arquitectura de tres capas:

Las llamadas de la interfaz del usuario en la estación de trabajo, al servidor de capa
intermedia, son más flexibles que en el diseño de dos capas, ya que la estación solo necesita
transferir parámetros a la capa intermedia.
Con la arquitectura de tres capas, la interfaz del cliente no es requerida para comprender o
comunicarse con el receptor de los datos. Por lo tanto, esa estructura de los datos puede ser
modificada sin cambiar la interfaz del usuario en la PC.
El código de la capa intermedia puede ser reutilizado por múltiples aplicaciones si está
diseñado en formato modular.
La separación de roles en tres capas, hace más fácil reemplazar o modificar una capa sin
afectar a los módulos restantes.
 Desventajas de las Arquitecturas de Tres Capas y asadas en web
Los ambientes de tres capas pueden incrementar el tráfico en la red y requiere más balance
de carga u tolerancia a las fallas.
Los exploradores actuales no son todos iguales.
La estandarización entre diferentes proveedores ha sido lenta en desarrollarse. Muchas
organizaciones son forzadas a escoger uno en lugar de otro, mientras que cada uno ofrece
sus propias y distintas ventajas.
 ARQUITECTURA DE 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. Es la separación del código en tres capas diferentes, acotadas por
su responsabilidad, en lo que se llaman Modelos, Vistas y Controladores.
En el siguiente podemos ver las 3 capas diferente están son:

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 hacen 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 SOA

SOA, o Arquitectura Orientada a Servicios, define un método para hacer que los componentes
de software sean reutilizables a través de interfaces de servicio. Estas interfaces utilizan
 estándares de comunicación comunes entre sí, por lo que pueden incorporarse rápidamente a
nuevas aplicaciones sin una integración profunda cada vez. Cada servicio SOA contiene el
código y la integración de datos necesarios para realizar funciones comerciales completas y
discretas, como verificar el crédito de un cliente, calcular pagos mensuales de préstamos o
procesar solicitudes de hipotecas. Los servicios están débilmente acoplados, lo que significa
que se pueden invocar con poco o ningún conocimiento de la implementación de integración
subyacente. Los servicios se exponen mediante protocolos web estándar, como SOAP
(Protocolo simple de acceso a objetos),

Ventajas de la SOA

Mayor agilidad comercial: tiempo de comercialización más rápido: la eficiencia de ensamblar

aplicaciones a partir de interfaces de servicio reutilizables, en lugar de reescribir y reintegrar
cada nuevo proyecto de desarrollo, permite a los desarrolladores crear aplicaciones más
rápidamente para responder a nuevas oportunidades comerciales. 

Capacidad para aprovechar la funcionalidad heredada en nuevos mercados: una SOA bien
diseñada permite a los desarrolladores ampliar fácilmente la funcionalidad bloqueada en una
plataforma o entorno informático a nuevos entornos y mercados. Por ejemplo, muchas
empresas utilizan SOA para exponer la funcionalidad de los sistemas financieros basados en
mainframe en la Web.
 Colaboración empresarial-TI mejorada: en SOA, los servicios se pueden definir en términos
comerciales (por ejemplo, generar cotización de seguros o calcular el retorno de la inversión de
equipo de capital).

Ejemplo de SOA
Para 2010, las implementaciones de SOA iban a toda marcha en empresas líderes en
prácticamente todas las industrias. Por ejemplo:

 Delaware Electric recurrió a la SOA para integrar sistemas que antes no se comunicaban entre
sí, lo que generó eficiencias de desarrollo que ayudaron a la organización a mantenerse
solvente durante un congelamiento de cinco años por mandato estatal de las tarifas eléctricas.
 Cisco adoptó la SOA para asegurarse de que su experiencia de pedidos de productos fuera
consistente en todos los productos y canales exponiendo los procesos de pedidos como
servicios que las divisiones, adquisiciones y socios de negocios de Cisco podrían incorporar a
sus sitios web.
 Independence Blue Cross (IBC) de Filadelfia implementó una SOA para asegurar que los
diferentes componentes que se ocupan de los datos de los pacientes —agentes del servicio al
cliente de IBC, consultas médicas, usuarios del sitio web de IBC— estuvieran funcionando con
la misma fuente de datos (una “versión única de la verdad”).

Las 9 capas de SOA y cómo interactúan entre ellas:

 cabe mencionar que no necesariamente tienen que comunicarse exclusivamente con la inmediata
superior o inferior, es posible que se puedan relacionar capas que no sean consecutivas. Se puede
apreciar que la capa de consumidores se puede comunicar de manera directa con la capa de
servicios, omitiendo la capa de proceso de negocio.
 Capa Operacional: Esta capa incluye todas las aplicaciones heredadas que ya se tengan en
producción y que soporten las actividades del negocio.
 Capa de Componentes de Servicio: Esta capa contiene componentes de servicio, cada
 uno de ellos provee la implementación, para la realización de las operaciones de los servicios.
 Capa de Servicios: Esta capa contiene todos los servicios definidos dentro de SOA. El
servicio se considera una especificación abstracta de una colección de funciones alineadas al
negocio.
 Capa de Procesos de Negocio: En esta capa se forman las composiciones y coreografía
de servicios que responden a los procesos del negocio.
 Capa de Consumidores: Esta capa es la que provee a los usuarios las funcionalidades de
IT.
 Capa de Integración: Es la parte más importante de SOA, pues provee la capacidad de
mediación, la ruta y las solicitudes de servicio de transporte del solicitante del servicio con el
proveedor de servicio correcto.
 Capa de Calidad de Servicios: Es la capa que provee las realizaciones de los
requerimientos no funcionales del negocio.
 Capa de la Arquitectura de la Información: Es la capa que se ocupa de la arquitectura de
datos, modelar y diseñar la data de manera que sea escalable en el tiempo.
 Capa de Gobierno: Esta capa abarca todos los aspectos del negocio de vida operativa de
gestión del ciclo de SOA. Proporciona orientación y las políticas para la toma de decisiones acerca
de una arquitectura SOA y la gestión de todos los aspectos de una solución de SOA, incluyendo la
capacidad, rendimiento, seguridad y monitoreo.

EMPRESAS, SECTORES QUE APLIQUEN LAS ARQUITECTURAS

WSO2 es una compañía que desarrolla aplicaciones de software open source enfocadas en proveer
una arquitectura orientada a servicios para desarrolladores profesionales, entre sus principales
productos podemos encontrar ESB (Enterprise Service Bus) pieza fundamental para una arquitectura
orientada a servicios.

ESB (Enterprise Service Bus) es solo uno de los productos de WSO2, existen otros complementarios
como Identity Server o Message Broker, productos que completan una larga lista de todo lo que
WSO2 ofrece. La elección de los productos de WSO2 para la implementación de una arquitectura
SOA deben estar basados en las necesidades que se desean cubrir, para esto es imprescindible realizar
las pruebas que aseguren que los productos seleccionados cumplen las expectativas. Y para esto
WSO2 pone a disposición sin ningún tipo de restricción todos los productos para ser descargados,
instalados y modificados.

WSO2 ofrece todo lo necesario para la construcción de este tipo de arquitecturas, sin embargo, se
debe contar con soporte profesional que guíe y evalúe los pasos para un objetivo final en las fases de
desarrollo, pruebas y despliegue.

Iniciar una arquitectura orientada a servicios con los productos open source que WSO2 ofrece resulta
factible, de toda manera el camino no se debe recorrer en solitario, contar con soporte profesional que
monitorice parámetros será clave para implementar una arquitectura orientada a servicios eficaz de la
mano de WSO2.

PATRONES DE DISEÑO CREACIONALES

Singleton
Objetivo: Crea un único elemento y mantenerlo durante el tiempo deseado en la ejecución del
programa.

Principalmente, el patrón singleton te permite crear una instancia de un objeto una vez, y luego
usarlo cada vez que lo necesite, en lugar de crear uno nuevo sin tener que hacer un seguimiento
de una referencia a él, ya sea globalmente o simplemente pasándolo como una dependencia en
todas partes.

En Javascript, se puede implementar de dos maneras, mediante el uso de IIFE o

mediante el uso de clases de ES6 (forma que personalmente prefiero). La
implementación quedaría de la siguiente manera.

Factory
Objetivo: Crear instancias de objetos de otras clases mediante la encapsulación de la creación de
los mismos.

Este patrón suele ser confuso, puesto que tiene dos vertientes principales: el factory method y
el abstract factory. Pero ambas vertientes se componen de las mismas partes:

 Producto: Define la interfaz de los objetos que crea el método de fabricación.

 Producto concreto: Implementa la interfaz del producto.
 Creador: Declara los métodos para fabricar y devuelve un objeto solicitado.
 Creador concreto: Redefine el método de fabricación para devolver una instancia del
producto concreto.

Factory method

En esencia, el factory method te permite centralizar la lógica de crear objetos (es decir, qué
objeto crear y por qué) en un solo lugar, y con ello, que te olvides de esa parte, para centrarte en
simplemente solicitar el objeto que se necesita y luego usarlo.

Abstract factory

Mejor conocido por ser una fábrica de fábricas.

Objetivo: Encapsular un grupo de fábricas individuales con un objetivo común. Separa los
detalles de la implementación de un conjunto de objetos de su uso general.

Builder
Objetivo: Permite construir un objeto indicando, lo que debe hacer para realizar su trabajo.

El patrón Builder permite a un cliente construir un objeto complejo especificando sólo el tipo y
el contenido. Los detalles de construcción están ocultos del cliente por completo.

La motivación más común para usar Builder, es simplificar el código del cliente que crea
objetos complejos. El cliente aún puede dirigir los pasos tomados por el constructor sin saber
cómo se realiza el trabajo real. Los constructores con frecuencia encapsulan la construcción de
objetos compuestos (otro patrón de diseño de GoF), porque los procedimientos involucrados
son a menudo repetitivos y complejos.
 Por lo general, es el último paso el que devuelve el objeto recién creado, lo que facilita que un
constructor participe en interfaces fluidas en las que múltiples llamadas de métodos, separadas
por operadores de punto, se encadenan juntas.

Prototype
Objetivo: Especifica los tipos de objetos para crear utilizando una instancia prototípica y crea
nuevos objetos copiando este prototipo.

El patrón Prototype crea nuevos objetos, pero en lugar de crear objetos no inicializados,
devuelve objetos que se inicializan con valores que copió de un prototipo u objeto de muestra.
El patrón de Prototype también se conoce como el patrón de propiedades.

Los lenguajes clásicos rara vez usan el patrón Prototype, pero JavaScript, como lenguaje
prototípico, usa este patrón en la construcción de nuevos objetos y sus prototipos.

PATRONES DE DISEÑO ESTRUCTURALES

Adapter
Analogía en el mundo real

Una maleta antes y después de un viaje al extranjero.

Bridge
 Realizar incluso un cambio sencillo en una base de código monolítica es bastante difícil
porque debes comprender todo el asunto muy bien. Es mucho más sencillo realizar
cambios en módulos más pequeños y bien definidos.

Composite
Analogía en el mundo real

Un ejemplo de estructura militar

Decorator

Analogía en el mundo real

Obtienes un efecto combinado vistiendo varias prendas de ropa.

Facade
Analogía en el mundo real

Haciendo pedidos por teléfono.

Flyweight
 Proxy

Analogía en el mundo real

Las tarjetas de crédito pueden utilizarse para realizar pagos tanto como el efectivo.
 PATRONES DE DISEÑO COMPORTAMENTALES

Command

Analogía en el mundo real

Realizando un pedido en un restaurante.

Observer
Analogía en el mundo real

Suscripciones a revistas y periódicos.

 Strategy

Analogía en el mundo real

Varias estrategias para llegar al aeropuerto.

 Template Method

Analogía en el mundo real

Un plan arquitectónico típico puede alterarse ligeramente para que encaje mejor con las
necesidades del cliente.

BEST PRACTICE DE PROGRAMACION

La mayoría de los desarrolladores coincidimos en que existen al menos dos caminos para mejorar
como programadores. El primero es un camino tecnológico mediante el cual el programador
avanza en el estudio y la especialización de nuevos lenguajes y herramientas. 
El segundo camino, quizás menos explorado por la mayoría, pero no menos importante, es el
camino de las buenas prácticas en programación informática.

Las 10 buenas prácticas de programación:

1. Prioriza la legibilidad
2. Estructura la arquitectura
3. Lee mucho código fuente
4. Coloca comentarios
5. Testea tu código.
6. Simplifica al máximo.
7. Realiza control de versiones
8. No reproduzcas fragmentos idénticos de código.
9. Evita los elementos no habituales
10. No utilices caracteres únicos del español.

CARACTERÍSTICAS DE UN BUEN PROGRAMADOR

 Es autodidacta
 Evita la frustración.
 Apuesta por la innovación.
 Observa con detenimiento.

COMPARACION ENTRE GITHUB Y GITLAB

GITHUB GITLAB
1. Máximo de 3 colaboradores gratis. 1.No hay limites de colaboradores
2. Ofrece hasta 500 MB. 2.El limite gratis por repositorio es de 10
GB
3. El código se puede descargar como 3.Permite incluir adjuntos en un issue o
archivo problema.
4. Opción de lectura o escritura por 4.Puedes proporcionar acceso a
repositorio. determinadas partes de un proyecto.
5. Supera los 35 millones proyectos. 5.Mas de 100 mil proyectos.