PROGRAMACION ORIENTADA A OBJETOS II

Presentación del tema: "PROGRAMACION ORIENTADA A OBJETOS II"— Transcripción de la presentación:

1 PROGRAMACION ORIENTADA A OBJETOS II
Unidad 01 ARQUITECTURAS por capas

2 Arquitecturas de Sistemas
La Arquitectura Cliente-Servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

3 Arquitecturas de Sistemas
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

4 Arquitecturas de Sistemas
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta.

5 Arquitecturas de Sistemas
Características En la arquitectura C/S el remitente de una solicitud es conocido como Cliente. Sus características son: Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectarse a varios servidores a la vez. Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario. Al contratar un servicio de redes , se tiene que tener en la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.

6 Arquitecturas de Sistemas
Al receptor de la solicitud enviada por el cliente se conoce como Servidor. Sus características son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado). No es frecuente que interactúen directamente con los usuarios finales.

7 Introducción a J2EE - Arquitectura
Arquitectura de 2 Capas – Cliente - Servidor

8 Introducción a J2EE - Arquitectura
Arquitectura de 2 Capas – Cliente - Servidor La lógica de negocio y la lógica de presentación son mezcladas, lo que resulta difícil de entender el sistema y realizar mantenimiento

9 Arquitectura de 3 Capas La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos.

10 Arquitectura de 3 Capas Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas).

11 Arquitectura de 3 Capas Capa de Presentación: es 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.

12 Arquitectura de 3 Capas

13 Arquitectura de 3 Capas

14 Arquitectura de 3 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.

15 Arquitectura de 3 Capas

16 Arquitectura de 3 Capas

17 Arquitectura de 3 Capas

18 Arquitectura de 3 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.

19 Arquitectura de 3 Capas

20 Arquitectura de 3 Capas

21 Arquitectura de 3 Capas

22 Arquitectura de 3 Capas

23 Arquitectura de 3 Capas

24 Modelo Vista Controlador
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

25 Modelo Vista Controlador
Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

26 Modelo Vista Controlador
Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

27 Modelo Vista Controlador
Vista: Componentes visuales encargados de construir la interfaz de usuario. Ejemplo: login.jsp: <html> <body> <form action="/login"> <input type="text" name="user"/> <input type="text" name="password"/> </form> </body> </html>

28 Modelo Vista Controlador
Controlador: Tienen la tarea de administrar el flujo de formularios y de invocar a los componentes con la lógica de negocio (o sea, de la capa Model). Ejemplo: LoginServlet.java class LoginServlet extends HttpServlet{ void doPost(HttpServletRequest request, HttpServletResponse response){ Validador validador = new Validador(); boolean tieneAcceso = validador.validarUsuario(request.getParameter("user"), request.getParameter("password")); if (tieneAcceso){ response.sendRedirect("/bienvenido.jsp"); }else{ response.sendRedirect("/error.jsp"); }

29 Modelo Vista Controlador
Modelo: Componentes con acceso a las entidades persistentes y la lógica propia del negocio. Ejemplo: Validador.java class Validador{ boolean validarUsuario(String user, String pass) { boolean validado = false; getStmt(); resultado= stmt.executeQuery("SELECT * FROM USERS WHERE Usuario=" + user + “ AND Password=“+ pass); if(resultado.next) validado=true; else validado=false return validado; }