PA121-01 SISTEMA DE GESTIÓN DEL CONOCIMIENTO PARA LA DEFINICIÓN DE ESTRATEGIAS QUE EVITEN LA DESERCIÓN ESCOLAR EN LOS COLEGIOS DE MOCOA – PUTUMAYO EN EL NIVEL DE EDUCACIÓN BÁSICA SECUNDARIA JOSÉ MANUEL BURBANO CARVAJAL PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA MAESTRÍA EN INGENIERÍA DE DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2013 PA121-01 SISTEMA DE GESTIÓN DEL CONOCIMIENTO PARA LA DEFINICIÓN DE ESTRATEGIAS QUE EVITEN LA DESERCIÓN ESCOLAR EN LOS COLEGIOS DE MOCOA – PUTUMAYO EN EL NIVEL DE EDUCACIÓN BÁSICA SECUNDARIA Autor: José Manuel Burbano Carvajal DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA Director Ing. Juan Carlos Guevara Bolaños, MsC. PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2013 Tabla de contenido TABLA DE FIGURAS......................................................................................................................... 4 INTRODUCCIÓN ......................................................................................................................... 5 1. ARQUITECTURA DE TRES CAPAS ............................................................................................. 6 2. CAPA DE PRESENTACIÓN O CAPA DE CLIENTE ......................................................................... 6 3. CAPA DE DOMINIO DE LA APLICACIÓN O CAPA DE NEGOCIO .................................................. 6 4. CAPA DEL REPOSITORIO O CAPA DE SERVIDOR DE DATOS ...................................................... 6 5. VENTAJAS DE USAR LA ARQUITECTURA DE TRES CAPAS ......................................................... 7 6. DESVENTAJAS DE USAR LA ARQUITECTURA DE TRES CAPAS.................................................... 7 7. MAPEO DE LA ARQUITECTURA AL SISTEMA DE GESTIÓN DEL CONOCIMIENTO PROPUESTO ... 8 REFERENCIAS ................................................................................................................................. 9 TABLA DE FIGURAS Figura 1. Arquitectura en tres capas: Cliente, aplicación y almacenamiento .................................. 7 Figura 2. Arquitectura del Sistema Propuesta ................................................................................ 9 INTRODUCCIÓN En las aplicaciones distribuidas, partiendo del modelo Cliente/Servidor, al aumentar la complejidad de los procesos se acaba con el denominado problema del "cliente pesado” [1]. Al poner la mayor parte del código necesario para llevar a cabo los procesos en el cliente, este debe descargar del servidor los datos necesarios para llevarlos a cabo. Esto es muy ineficiente por dos razones principales: - La red sufre una gran carga debido a las múltiples descargas de cada uno de los clientes. La gran dependencia en el rendimiento del hardware en el lado del cliente. De manera que aparece la arquitectura en tres niveles que divide la funcionalidad para optimizar el uso de recursos, con este tipo de arquitectura se consigue soluciones mucho más flexibles y escalables, las tres capas son las siguientes: - Capa de Presentación o capa de cliente. Capa de dominio de la aplicación o capa de negocio. Capa del repositorio o capa de servidor de datos. 1. ARQUITECTURA DE TRES CAPAS La arquitectura de tres capas [1] 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 basada en Web transforma la interfaz de búsqueda existente (el explorador de Web), en la interfaz del usuario final. 2. CAPA DE PRESENTACIÓN O CAPA DE CLIENTE Contiene los componentes de usuario que son únicos para cada uno de ellos. Esto es la lógica de aplicación específica del usuario y la interfaz [2]. De manera que reúne todos los aspectos del software que tiene que ver con las interfaces y la interacción con los diferentes tipos de usuarios [3], estos aspectos incluyen el manejo y el aspecto de ventanas, el formato de los reportes, menúes, gráficos y elementos de multimedia en general. Los componentes del nivel de usuario, proporcionan la interfaz visual que los clientes utilizarán para ver la información y los datos. En este nivel, los componentes son responsables de solicitar y recibir servicios de otros componentes del mismo nivel o del nivel de servicios de negocio. Es muy importante destacar que, a pesar de que las funciones del negocio residen en otro nivel, para el usuario es transparente la forma de operar. 3. CAPA DE DOMINIO DE LA APLICACIÓN O CAPA DE NEGOCIO Esta capa constituye [2] un entorno multiusuario y mantiene las partes compartidas de la aplicación. Las operaciones con un uso intensivo de datos deben ejecutarse en este nivel. También es el punto donde se pueden llevar a cabo la coordinación de transacciones. Esta capa [3] reúne todos los aspectos de software que automatizan o apoyan los diferentes procesos de negocio que los usuarios llevan a cabo. Estos aspectos típicamente incluyen las tareas que forman parte de los procesos, reglas y restricciones. Como los servicios de usuario no pueden contactar directamente con el nivel de servicios de datos, es responsabilidad de los servicios de negocio hacer de puente entre estos. Los objetos de negocio proporcionan servicios que completan las tareas de negocio tales como verificar los datos enviados por el cliente. Antes de llevar a cabo una transacción en la base de datos. Los componentes de los servicios de negocio también sirven para evitar que el usuario tenga acceso directo a la base de datos, lo cual proporciona mayor seguridad en la integridad de ésta. 4. CAPA DEL REPOSITORIO O CAPA DE SERVIDOR DE DATOS Esta capa se [2] especialista en dar un servicio de persistencia a los datos de la aplicación y permite manejar grandes volúmenes de ellos, mediante la capa de negocio, se puede encargar de ofrecer, modificar, almacenar, borrar y recuperar datos, mediante el gestor (o los gestores) de bases de datos que la aplicación requiera. A continuación se da a conocer en la Figura 1 la arquitectura de tres capas que se aplicará en el sistema de gestión del conocimiento: Figura 1. Arquitectura en tres capas: Cliente, aplicación y almacenamiento 5. VENTAJAS DE USAR LA ARQUITECTURA DE TRES CAPAS Las ventajas de usar la arquitectura de tres capas son las siguientes: - - Los componentes de la aplicación pueden ser desarrollados en cualquier lenguaje. Los componentes son independientes. Los componentes pueden estar distribuidos en múltiples servidores. La base de datos es solo vista desde la capa intermedia y no desde los clientes. Mejora la administración de los recursos cuando existe mucha concurrencia. Permite reutilización real del software y construir aplicación escalable. 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. 6. DESVENTAJAS DE USAR LA ARQUITECTURA DE TRES CAPAS Las desventajas de usar la arquitectura de tres capas son las siguientes: - 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. 7. MAPEO DE LA ARQUITECTURA AL SISTEMA DE GESTIÓN DEL CONOCIMIENTO PROPUESTO El Sistema de Gestión del Conocimiento que se propone tendrá la arquitectura de las tres capas, la primera capa será la del cliente [Los componentes del nivel de usuario proporcionan la interfaz visual que los usuarios utilizarán para visualizar la información y los datos. En este nivel, los componentes son los responsables de solicitar y recibir servicios de otros componentes de la misma capa o la capa de negocio, de manera que el servidor de aplicaciones se comunica directamente con el servidor de componentes. La capa de negocios como los servicios de usuario, no pueden contactar directamente con el nivel de servicios de datos, es responsabilidad de los servicios de negocio hacer puente entre estos. Los objetos de negocio proporcionan servicios que completan las tareas de negocio tales como verificar los datos enviados por el usuario. Esta capa de negocios sirve para evitar que el usuario tenga acceso directo a la base de datos, lo cual proporciona mayor seguridad en la integridad de ésta. Para esta capa se tendrá dos servidores, el servidor web donde se tendrá el servidor de aplicaciones (glashfish) y las paginas JSF que permite la navegación del sistema. En el servidor de componentes se aplicará la lógica del negocio donde se usará JEE6 y el API que administra las ontologías JENA. JENA manejará la ontología implementada dentro del sistema. Se tendrá acceso a la capa de servidor de datos a través del acceso de datos. La capa de servidor de datos se encarga de las típicas tareas que se realiza con los datos: inserción, modificación, consulta y borrado. La lógica de negocio no debe ser implementada en la capa de servidor de datos, aunque un componente de servicios de datos es responsable de la gestión de las peticiones realizadas por un objeto de negocio. Para esta capa se utilizará MySQL, lo cual ayudará administrar la información necesaria que alimente el sistema. A continuación se representa la arquitectura propuesta mapeada a nuestra necesidad: Figura 2. Arquitectura del Sistema Propuesta REFERENCIAS [1]. http://prograweb.com.mx/pweb/0201arquiAplicaweb.html [2]. Arquitectura de Software. Disponible Online: http://ocw.udl.cat/enginyeria-iarquitectura/enginyeria-del-software-iii/Continguts/1%20-%20Introduccion/2-Arquitectura.pdf [3]. Jim Conallen: “Building Web Applications with UML”. Addison Wesley, 1999. ISBN: 0-20161577-0