ARQUITECTURA

APLICACIONES
EMPRESARIALES
Jorge E. Freile Mejia
1. Contenido
UNIDAD TEMA GENERAL TEMA ESPECIFICO

1.1 Explicación general de la POO

1.2 Introducción a los sistemas distribuidos
1.3 Modelos de comunicación en sistemas distribuidos
Introducción a las aplicaciones
1 1.4 Aplicaciones en capas
distribuidas
1.5 Aplicabilidad de la implementación en capas
1.6 Tecnologías: CORBA a través de SOCKTES
1.7 Tecnología CORBA a través de RMI

2.1 Integración de aplicaciones distribuidas en la Web

Integración de aplicaciones distribuidas 2.2 Remoting Procedure Call – RPC
2
en la Web 2.3 Servicios Web – SOAP
2.4 Servicios Web -REST

3.1 Introducción e importancia de los patrones

3 Diseño de Patrones 3.2 Patrones creacionales
3.3 Patrones de comportamiento y estructurales
1.3 Aplicaciones en Capas
La programación por capas es un modelo de desarrollo software en el que el
objetivo primordial es la separación (desacoplamiento) de las partes que
componen un sistema software o también una arquitectura cliente-servidor: lógica
de negocios capa de presentación y capa de datos. De esta forma, por ejemplo,
es sencillo y mantenible crear diferentes interfaces sobre un mismos sistema sin
requerirse cambio alguno en la capa de datos o lógica.
1.3 Aplicaciones en Capas
Consumo y exposición de funcionalidades
en las capas que son inmediatamente
subyacentes

Práctica recomendada: No Saltar Capas,

para respetar el bajo acoplamiento y la alta
cohesión
1.3 Aplicaciones en Capas
1.3 Aplicaciones en Capas
Capa de datos: es donde residen los datos y es la encargada de acceder a
los mismos. Está formada por uno o más gestores de bases de datos que
realizan todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
1.3 Aplicaciones en Capas
Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario
y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del
negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la
capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se
consideran aquí los programas de aplicación.
1.3 Aplicaciones en Capas
Capa de presentación: la que ve el usuario (también se la denomina "capa de
usuario"), presenta el sistema al usuario, le comunica la información y captura la
información del usuario en un mínimo de proceso (realiza un filtrado previo para
comprobar que no hay errores de formato). También es conocida como interfaz
gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar)
para el usuario. Esta capa se comunica únicamente con la capa de negocio.
Principios de diseño en arquitectura

El objetivo de este principio conseguir desacoplar las clases. En todo diseño

siempre debe existir un acoplamiento pero hay que evitarlo en la medida de lo
posible. Un sistema no acoplado no hace nada pero un sistema altamente
acoplado es muy difícil de mantener.

El objetivo de este principio es el uso de abstracciones para conseguir que una

clase interactue con otras clases sin que las conozca directamente. Es decir, las
clases de nivel superior no deben conocer las clases de nivel inferior. Dicho de
otro modo, no debe conocer los detalles. Existen diferentes patrones como la
inyección de dependencias o service locator que nos permiten invertir el control.
3 Principios Básicos de Diseño
1. Diseño Robusto Beneficio: Bajo Acoplamiento(Grado de
relacionamiento entre los elementos) y Alta
2. Diseño con Calidad Cohesión(Asignación única de responsabilidades
3. Independencia de la Tecnología Ej. Licuadora)

Técnicas de Diseño - No confundir con POO

1. Modularización: Divide y vencerás (responsabilidad independiente)
2. Abstracción: Elementos más relevantes para atacar los problemas de forma más simple,
permite el ocultamiento de los elementos del Soft. Ej: Para poder explicar el funcionamiento de
un vehículo no nos interesa internamente cuáles elementos pose.
Ej: Iceberg
3. Encapsulamiento: Ocultar la complejidad interna de la arquitectura de los componentes.
Principios Solid
Principios de diseño en arquitectura

Este principio trata de destinar cada clase a una finalidad sencilla y concreta. En
muchas ocasiones estamos tentados a poner un método reutilizable que no
tienen nada que ver con la clase simplemente porque lo utiliza y nos pilla más a
mano. En ese momento pensamos "Ya que estamos aquí, para que voy a crear
una clase para realizar esto. Directamente lo pongo aquí".

El problema surge cuando tenemos la necesidad de utilizar ese mismo método

desde otra clase. Si no se refactoriza en ese momento y se crea una clase
destinada para la finalidad del método, nos toparemos a largo plazo con que las
clases realizan tareas que no deberían ser de su responsabilidad.
Principios de diseño en arquitectura

habla de crear clases extensibles sin necesidad de entrar al código fuente a

modificarlo. Es decir, el diseño debe ser abierto para poderse extender pero
cerrado para poderse modificar. Aunque dicho parece fácil, lo complicado es
predecir por donde se debe extender y que no tengamos que modificarlo. Para
conseguir este principio hay que tener muy claro como va a funcionar la
aplicación, por donde se puede extender y como van a interactuar las clases.

El uso más común de extensión es mediante la herencia y la reimplementación

de métodos. Existe otra alternativa que consiste en utilizar métodos que acepten
una interface de manera que podemos ejecutar cualquier clase que implemente
ese interface. En todos los casos, el comportamiento de la clase cambia sin que
hayamos tenido que tocar código interno.
Principios de diseño en arquitectura

habla de la importancia de crear todas las clases derivadas para que también
puedan ser tratadas como la propia clase base. Cuando creamos clases
derivadas debemos asegurarnos de no re-implementar métodos que hagan que
los métodos de la clase base no funcionen si se tratasen como un objeto de esa
clase base.
Principios de diseño en arquitectura

trata de algo parecido al primer principio. Cuando se definen interfaces estos

deben ser específicos a una finalidad concreta. Por ello, si tenemos que definir
una serie de métodos abstractos que debe utilizar una clase a través de
interfaces, es preferible tener muchos interfaces que definan pocos métodos
que tener un interface con muchos métodos.

El objetivo de este principio es principalmente poder reaprovechar los

interfacesen otras clases.
Capas en Netbeans
Arq por capas - Ventajas
- Busca Escalabilidad - Sistemas a gran escala
- Busca Reutilización - Facil de entender
- Busca Organizacion -
- Trata de cumplir los principios
S.O.L.I.D
- Restricciones Claras
- Separación de intereses
- Asignación clara de responsabilidades
- Bajo Acoplamiento, Alta Cohesión
- Mejora la mantenibilidad
Arq por capas - Desventajas

- No está orientada al desempeño

- No está orientada a la seguridad
- No está orientada a la usabilidad
- No es fácil de implementar correctamente
- Implementar una mayor cantidad de componentes
- El desempeño se puede ver afectado
-
Arq por capas - Casos de uso
- Arquitectura simple
- Da una Estructura inicial a la aplicación
https://www.youtube.com/watch?v=SaTQGl41SZo