universidad nacional autÓnoma de...

UNIVERSIDAD NACIONAL AUTÓNOMA DE NICARAGUA

UNAN-LEÓN

FACULTAD DE CIENCIA Y TECNOLOGIA

Tesis para optar al título de Ingeniería en Sistemas de Información

“Desarrollo de una aplicación web para la gestión académica del Colegio Madre María Luisa”

Autores:

Br. Isidro Francisco Padilla Reyes.

Br. Levin Dany Pichardo Berrios.

Br. Sandra Patricia Sánchez García

Tutor:

Msc. Wilmer Matamoros.

León, Diciembre 2012

- 2 -

Dedicatoria

A mi madre Consuelo Reyes quien con su amor incondicional y esfuerzo me

dio la fuerza necesaria para cumplir mi sueño.

A mi abuela María Apolonia Reyes quien con su cariño y consejos me

reconforto y motivo para seguir adelante.

A mi padre Isidro Padilla quien con su apoyo me brindo el soporte y

respaldo que necesitaba para alcanzar mis metas.

Isidro Padilla

- 3 -

Dedicatoria

A mi madre, Manuela de Jesús Berríos (q.e.p.d) por quien decidí emprender

mi carrera profesional, quien con sus palabras alentó en mi el deseo de ser una

persona de bien y siendo la primera en creer que si lo podía lograr.

A mi padre, Santos Alberto Pichardo Zamora, quien con su humildad y

sencillez me recuerda que no debo olvidar mi procedencia y menos mi horizonte.

A mi tío y padrino, Francisco José Berríos, quien motivo en mi el deseo de

superación y con su ejemplo de vida sigue mostrando que si se pueden alcanzar

nuestras metas, con esfuerzo, dedicación y disciplina, aun contra pronósticos.

Y a mis familiares más cercanos, que también han creído en mí y me han dado

todo su apoyo moral y sentimental para continuar con mis sueños.

Levin Pichardo

- 4 -

Dedicatoria

A mi abuelo, el Sr Hugo Rolando García Arana (q.e.p.d.) quien con el

amor y la dedicación que solo un padre puede tener me permitió dar los primeros

pasos que me ayudaron a emprender el camino hasta convertirme en profesional.

A mi abuela, la Profesora Elia Marina Baca que me ayudo a ser paciente y

perseverante hasta alcanzar mi meta con su propio ejemplo de paciencia y amor

de madre que me tuvo desde la infancia.

A mi madre, la Profesora Elia García Mairena quien con un gran esfuerzo

me ayudo a culminar este camino cuesta arriba y con su ejemplo de mujer

luchadora me motiva a seguir adelante y no renunciar nunca a mis sueños.

A los demás miembros de mi familia que con consejos, regaños, cariño y risas

me dieron valor y confianza en mí misma.

Sandra Sánchez

- 5 -

Agradecimientos

Agradecemos a Dios, por sobre todas las cosas, quien nos dio la vida y nos ha

dado la sabiduría y el entendimiento para lograr nuestros propósitos.

A nuestras familias, quienes nos dieron palabras oportunas, animo, cariño y

confianza en nosotros mismos.

A nuestros compañeros de clases, quienes compartieron con nosotros sus

conocimientos y más importante aun su amistad sincera.

Y a todos los docentes que de una y otra manera colaboraron con nosotros en

este trabajo de tesis, y que nos compartieron sus conocimientos en el transcurso

de esta carrera.

- 6 -

INDICE

INTRODUCCIÓN ...................................................................................................... - 9 - 1.1. OBJETIVOS ................................................................................................... - 10 -

1.1.1. OBJETIVO GENERAL .......................................................................... - 10 - 1.1.2. OBJETIVOS ESPECIFICOS ................................................................. - 10 -

MARCO TEORICO ................................................................................................. - 11 - 2.1 INTERNET ...................................................................................................... - 11 -

2.2 WEB ................................................................................................................. - 12 - 2.2.1. FUNDAMENTOS DE LA WEB ............................................................ - 12 -

2.3. SISTEMA DE GESTION ACADÉMICA ..................................................... - 12 -

2.4. PORTAL WEB ............................................................................................... - 12 - 2.5. APLICACIONES WEB .................................................................................. - 13 -

2.5.1. ANTECEDENTES .................................................................................. - 14 -

2.5.2. CONSIDERACIONES TECNICAS ....................................................... - 14 - 2.5.3. ESTRUCTURA DE APLICACIONES WEB ........................................ - 15 -

2.5.4. VENTAJAS Y DESVENTAJAS ............................................................ - 15 - 2.6. PROGRAMACION WEB .............................................................................. - 16 - 2.7. PARADIGMA DE LA PROGRAMACION .................................................. - 17 -

2.8. CLIENTE-SERVIDOR .................................................................................. - 17 - 2.9. SSL .................................................................................................................. - 18 -

2.10. SEGURIDAD WEB ..................................................................................... - 19 -

2.11. RIESGOS DEL ENTORNO WEB ............................................................... - 20 -

2.11.1. BLANCOS ATRACTIVOS .................................................................. - 20 - 2.11.2. PRESIONES DE NEGOCIO ................................................................ - 20 -

2.11.3. DEBILIDADES DE HTTP ................................................................... - 21 - 2.11.4. MITOS DE LA SEGURIDAD WEB .................................................... - 21 - 2.11.5. AMENZAS COMUNES ....................................................................... - 21 -

2.11.6. DESCRIPCION DE ALGUNOS ATAQUES ...................................... - 22 -

METODOLOGÍA DE TRABAJO .......................................................................... - 27 - 3.1. MÉTODOS ..................................................................................................... - 27 -

3.2. CICLO DE VIDA ........................................................................................... - 28 -

3.3. CICLO DE VIDA EN CASCADA ................................................................. - 28 -

3.4. ETAPAS DEL MODELO EN CASCADA .................................................... - 29 - 3.4.1. ANALISIS DE REQUERIMIENTOS .................................................... - 29 - 3.4.2. DISEÑO DEL SISTEMA ....................................................................... - 29 - 3.4.3. DISEÑO DEL PROGRAMA .................................................................. - 29 - 3.4.4. CODIFICACION O PROGRAMACION ............................................... - 29 -

3.4.5. PRUEBAS ............................................................................................... - 29 -

ANALISIS DEL SITEMAS ..................................................................................... - 30 - 4.1. ESPECIFICACIÓN DE REQUISITOS SOFTWARE ................................... - 30 -

4.1.1. INTRODUCCION .................................................................................. - 30 - 4.1.2. DESCRIPCIÓN GENERAL ................................................................... - 31 -

4.2. REQUISITOS ESPECIFICOS ....................................................................... - 33 -

- 7 -

4.2.1. REQUISITOS COMUNES DE INTERFACES ..................................... - 33 - 4.2.2. REQUISITOS FUNCIONALES ............................................................ - 34 - 4.2.3. REQUISITOS NO FUNCIONALES ...................................................... - 52 -

DISEÑO DEL SISTEMAS ...................................................................................... - 54 - 5.1. DIAGRAMA DE CASOS DE USO ............................................................... - 54 - 5.2. DIAGRAMAS DE SECUENCIA .................................................................. - 55 - 5.3. DIAGRAMA DE CLASES ............................................................................ - 67 -

5.3.1. CAPA PERSISTENCIA (Capa de Negocios)......................................... - 67 - 5.3.2. CAPA PROCESO (Capa de Aplicación) ................................................ - 68 - 5.3.3. CAPA PAGINA (Capa de Usuario) ........................................................ - 70 -

5.4. DIAGRAMA ENTIDAD RELACION .......................................................... - 71 -

5.5. DISEÑO DE DATOS ..................................................................................... - 73 - 5.7. MODELO RELACIONAL ............................................................................. - 79 -

CODIFICACIÓN DEL SISTEMA ......................................................................... - 80 -

6.1. PHP ................................................................................................................. - 80 - 6.1.1. HISTORIA ............................................................................................... - 80 - 6.1.2. CARACTERISTICAS ............................................................................... - 81 -

6.2. ESTANDAR ZEND ....................................................................................... - 81 - 6.2.1. REGLAS DEL ESTANDAR .................................................................. - 82 -

6.2.2. FUNCIONES Y METODOS .................................................................. - 82 - 6.3. XAMPP ........................................................................................................... - 83 -

6.3.1. CARACTERISITICAS Y REQUISITOS ............................................... - 84 - 6.3.2. APLICACIONES .................................................................................... - 84 -

6.4. CSS ................................................................................................................. - 84 - 6.4.1. CSS 2.1 .................................................................................................... - 84 -

6.5. JAVA SCRIPT ................................................................................................ - 85 -

6.6. XHTML .......................................................................................................... - 85 - 6.6.1. VENTAJAS RESPECTO AL HTML ..................................................... - 85 -

6.7. SQL ................................................................................................................. - 86 - 6.7.1. ORIGENES Y EVOLUCION ................................................................... - 86 -

6.7.2. CARACTERISITICAS GENERALES ................................................... - 86 - 6.8. APACHE ........................................................................................................ - 87 -

6.8.1. CARACTERISITICAS ........................................................................... - 87 -

CONCLUSIONES .................................................................................................... - 89 -

RECOMENDACIONES .......................................................................................... - 90 -

BIBLIOGRAFÍA ...................................................................................................... - 91 -

ANEXOS ................................................................................................................... - 93 -

- 8 -

INDICE DE FIGURAS

Figura 5.2.1: D. Secuencia - Matricular Alumno ...................................................................... - 55 -

Figura 5.2.2: D. de Secuencia - Rematricular Alumno ............................................................. - 56 -

Figura 5.2.3: D. de Secuencia - Retirar Alumno....................................................................... - 56 -

Figura 5.2.4: D. de Secuencia - Registrar Docente .................................................................. - 57 -

Figura 5.2.5: D. de Secuencia - Retirar Docente ...................................................................... - 57 -

Figura 5.2.6: D. de Secuencia - Ingresar Asignatura ............................................................... - 58 -

Figura 5.2.7: D. de Secuencia - Retirar Asignatura .................................................................. - 58 -

Figura 5.2.8: D. de Secuencia - Asignar Materia ..................................................................... - 59 -

Figura 5.2.9: D. de Secuencia - Desasignar Materia ................................................................ - 59 -

Figura 5.2.10: D. de Secuencia - Ingresar Nota Parcial ........................................................... - 60 -

Figura 5.2.11: D. de Secuencia - Ingresar Nota Reparacion ................................................... - 60 -

Figura 5.2.12: D. Secuencia - Modificar Nota Parcial ............................................................. - 61 -

Figura 5.2.13: D. de Secuencia - Modificar Nota Reparacion .................................................. - 62 -

Figura 5.2.14: D. de Secuencia - Asignar Acta Calificaciones .................................................. - 63 -

Figura 5.2.15: D. de Secuencia - Asignar Acta Reparaciones .................................................. - 63 -

Figura 5.2.16: D. de Secuncia - Abrir Secciones ...................................................................... - 64 -

Figura 5.2.17: D. de Secuencia - Cerrar Secciones .................................................................. - 64 -

Figura 5.2.18: D. de Secuencia - Generar Certificado ............................................................. - 65 -

Figura 5.2.19: D. de Secuencia - Ingresar Noticia .................................................................... - 65 -

Figura 5.2.20: D. de Secuencia - Subir Imagen ........................................................................ - 66 -

Figura 5.2.21: D. de Secuencia - Eliminar Imagen ................................................................... - 66 -

Sistema de Gestión Académica Teothokos – SAGAT

- 9 -

INTRODUCCIÓN

INTRODUCCIÓN

Actualmente el Colegio Madre María Luisa que es donde será aplicado el sistema

de gestión, utiliza para el registro de matrícula, un formato en papel, éste es llenado con

los datos personales del alumno, que luego junto con otros documentos entregados

como requisitos para matricularse, pasan a ser parte del expediente del mismo.

La gestión de notas es llevada a cabo por la docencia, la secretaría y dirección, cada

docente lleva control de las calificaciones de sus alumnos, bimensualmente debe

entregar las calificaciones en un formato específico a la Dirección, la cual registra las

notas en un libro de actas.

La entrega de boletines se realiza bimensualmente, existe un formato de boletín,

cada alumno cuenta con un ejemplar único de este para todo el año, en el que los

profesores van registrando las notas de los mismos.

El pensum se elabora anualmente, la dirección entrega a cada docente una lista de

las asignaturas a impartir y en que grados impartirá las mismas. También se les asigna a

cada docente un grado el cual guiará, esto significa que será el encargado de llevar el

control de todas las calificaciones de los alumnos para luego entregar los boletines.

Los certificados de notas solicitados por los alumnos egresados, son elaborados

revisando los registros de los libros de actas académicos correspondientes al año en el

cual el alumno curso determinado grado.

La apertura de una sección adicional para un grado se hace en base a la cantidad de

alumnos que la dirección considera tener en su momento. Y la ubicación de un alumno

en otra sección se hace por medio del apellido del mismo o a consideración personal de

la dirección.

El presente trabajo tiene como fin la elaboración de un software que facilite el

registro y obtención de datos pertenecientes a cada uno de los procesos académicos del

Colegio Católico Madre María Luisa, el cual aún no cuenta con una automatización de

ninguna de las actividades académicas.

Con este sistema se almacenarán los datos de manera digital, para luego ser impresa

y archivada cierto tipo de información, también permitirá la generación de certificados,

estadísticas, noticias académicas, datos del centro, entre otros.


- 10 -

INTRODUCCIÓN

1.1. OBJETIVOS

1.1.1. OBJETIVO GENERAL

Elaborar un sistema con interfaz web para la Gestión Académica del colegio

Madre María Luisa.

1.1.2. OBJETIVOS ESPECIFICOS

Almacenar datos personales de los docentes y los alumnos del colegio.

Registrar las notas académicas de los alumnos.

Generar e imprimir boletines.

Presentar estadísticas referentes al rendimiento académico de los alumnos.

Mostrar información del centro y sus actividades académicas.

Permitir la actualización del pensum académico y la designación a los

docentes de las asignaturas a impartir.

Registrar información del centro y sus actividades académicas.


- 11 -

MARCO TEÓRICO

MARCO TEORICO

2.1 INTERNET

Internet, la red de redes, nace a mediados de la década de los setenta, bajo los

auspicios de DARPA, la Agencia de Proyectos Avanzados para la Defensa de Estados

Unidos. DARPA inició un programa de investigación de técnicas y tecnologías para

unir diversas redes de conmutación de paquetes, permitiendo así a los ordenadores

conectados a estas redes comunicarse entre sí de forma fácil y transparente.

De estos proyectos nació un protocolo de comunicaciones de datos, IP o Internet

Protocol, que permitía a ordenadores diversos comunicarse a través de una red, Internet,

formada por la interconexión de diversas redes.

A mediados de los ochenta la Fundación Nacional para la Ciencia norteamericana,

la NSF, creó una red, la NSFNET, que se convirtió en el backbone (el troncal) de

Internet junto con otras redes similares creadas por la NASA (NSINet) y el U.S. DoE

(Department of Energy) con la ESNET. En Europa, la mayoría de países disponían de

backbones nacionales (NORDUNET, RedIRIS, SWITCH, etc.) y de una serie de

iniciativas paneuropeas (EARN y RARE). En esta época aparecen los primeros

proveedores de acceso a Internet privados que ofrecen acceso pagado a Internet.

A partir de esta época, gracias entre otras cosas a la amplia disponibilidad de

implementaciones de la suite de protocolos TCP/IP (formada por todos los protocolos

de Internet y no sólo por TCP e IP), algunas de las cuales eran ya de código libre,

Internet empezó lo que posteriormente se convertiría en una de sus características

fundamentales, un ritmo de crecimiento exponencial, hasta que a mediados del 2002

empieza a descender ligeramente el ritmo de crecimiento.

A mediados de los noventa se inició el boom de Internet. En esa época el número de

proveedores de acceso privado se disparó, permitiendo a millones de personas acceder a

Internet, que a partir de ese momento ya se empezó a conocer como la Red, desbancado

a las demás redes de comunicación existentes (Compuserve, FidoNet/BBS, etc.). El

punto de inflexión vino marcado por la aparición de implementaciones de TCP/IP

gratuitas (incluso de implementaciones que formaban parte del sistema operativo) así

como por la popularización y abaratamiento de medios de acceso cada vez más rápidos

(módems de mayor velocidad, RDSI, ADSL, cable, satélite). El efecto de todos estos

cambios fue de “bola de nieve”: a medida que se conectaban más usuarios, los costes se

reducían, aparecían más proveedores e Internet se hacía más atractivo y económico, con

lo que se conectaban más usuarios, etc.

En estos momentos disponer de una dirección de correo electrónico, de acceso a la

web, etc., ha dejado de ser una novedad para convertirse en algo normal en muchos

países del mundo. Por eso las empresas, instituciones, administraciones y demás están

migrando rápidamente todos sus servicios, aplicaciones, tiendas, etc., a un entorno web

que permita a sus clientes y usuarios acceder a todo ello por Internet. A pesar del ligero

descenso experimentado en el ritmo de crecimiento, Internet está destinado a convertirse


- 12 -

MARCO TEÓRICO

en una suerte de servicio universal de comunicaciones, permitiendo una comunicación

universal.

2.2 WEB

La WWW (World Wide Web) o, de forma más coloquial, la web, se ha convertido,

junto con el correo electrónico, en el principal caballo de batalla de Internet. Ésta ha

dejado de ser una inmensa “biblioteca” de páginas estáticas para convertirse en un

servicio que permite acceder a multitud de prestaciones y funciones, así como a

infinidad de servicios, programas, tiendas, etc.

2.2.1. FUNDAMENTOS DE LA WEB

El éxito espectacular de la web se basa en dos puntales fundamentales: el protocolo

HTTP y el lenguaje HTML. Uno permite una implementación simple y sencilla de un

sistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de una

forma fácil, simplificando el funcionamiento del servidor y permitiendo que servidores

poco potentes atiendan miles de peticiones y reduzcan los costes de despliegue. El otro

nos proporciona un mecanismo de composición de páginas enlazadas simple y fácil,

altamente eficiente y de uso muy simple.

2.3. SISTEMA DE GESTION ACADÉMICA

El objetivo principal de un Sistema de Gestión académica es llevar un control

detallado del rendimiento académico del alumno, como también información relativa a

las materias y contenidos entregados, evaluaciones de profesores, etc. entregando

además, las herramientas que permitan efectuar una gestión más eficiente. Cuenta con

una serie de funciones adicionales, las cuales permitirán conservar información

histórica, tanto de los Planes y Programas de Estudio, como resultados finales de los

alumnos, contenido de materias realizadas, cursos realizados, etc.

La evaluación de los alumnos pueda ser efectuada por distintas formas de

organización como por ejemplo curso y niveles. A su vez, las asignaturas pueden ser

agrupadas en distintas áreas del conocimiento, permitiendo con esto separarlas según su

importancia, asignando distintos porcentajes si lo ameritaran.

2.4. PORTAL WEB

Un portal de Internet es un sitio web que ofrece al usuario, de forma fácil e

integrada, el acceso a una serie de recursos y de servicios relacionados a un mismo

tema. Incluye elementos como enlaces, buscadores, foros, documentos, aplicaciones,

compra electrónica, etc. Principalmente un portal en Internet está dirigido a resolver

necesidades de información específica de un tema en particular.

El término portal tiene como significado puerta grande, y precisamente su nombre

hace referencia a su función u objetivo que es, por lo general, el punto de partida de un

usuario que desea entrar y realizar búsquedas en la web u obtener información


- 13 -

MARCO TEÓRICO

importante de él. Se puede decir que un portal ofrece servicios para la navegación en el

Internet, logrando incrementar la intensidad de tráfico en el mismo.

Los portales normalmente tienen programación que requiere muchos recursos

computacionales y por su alto tráfico generalmente se hospedan en servidores de

Internet dedicados. Normalmente está desarrollado en algún lenguaje más poderoso y

complejo que HTML, puede ser PHP o Java, y generalmente está asociado a una base

de datos que almacena tanto la información que se quiere presentar como la que se

obtiene del usuario del portal. Dicha información es totalmente aprovechable y en el

caso de la empresa, la información que queremos presentar se debe poder administrar

desde un área diseñada para que un usuario común dentro de nuestra empresa, pueda

actualizarla, modificarla, añadir nuevo contenido, de tipo que sea, sin necesidad de

expertos ya que entre otros el concepto de usuario abarca también a nuestro personal

interno.

Pero también un portal es una herramienta que permite integrar soluciones para

múltiples tipos de usuarios de su empresa o negocio, sus clientes, proveedores,

vendedores, técnicos, ejecutivos, ingenieros, personal de soporte y servicios

administrativos y comparten entre todos, obviamente con los niveles de autorización

adecuada, la misma información en línea, que normalmente estará almacenada en una

base de datos a la que se accede a través de aplicaciones, muchas veces complejas que

hacen de intercambiadores de información.

Un portal es mucho más que una página web, porque es completamente dinámico,

este dinamismo depende del tipo de información, grado de participación y el número de

usuarios finales. Un portal no solo provee al usuario información, sino que la recopila,

lo que se espera es que éste interactúe con la empresa.

Existen tres modalidades de portales:

1. Portales horizontales, también llamados portales masivos o de propósito general, se

dirigen a una audiencia amplia, tratando de llegar a toda la gente con muchas cosas.

Como ejemplo de portales de esta categoría están Terra, AOL, AltaVista, UOL, Lycos,

Yahoo, MSN, Yandex, etc.

2. Portales verticales, se dirigen a usuarios para ofrecer contenido dentro de un tema

específico como puede ser un portal de música, empleo, inmobiliario, un portal de

finanzas personales, arte, educación o de deportes.

3. Portales diagonales, se trata de una mezcla entre el portal horizontal y el vertical. Se

trataría de portales que utilizan redes sociales o aplicaciones generalistas como

Facebook, Pokebook, LinkedIn, Flickr o YouTube... complementados con contenidos

y/o utilidades dirigidas a un público muy concreto.

2.5. APLICACIONES WEB

Es una aplicación software que se codifica en un lenguaje soportado por los

navegadores web en la que se confía la ejecución al navegador. Una página Web puede

contener elementos que permiten una comunicación activa entre el usuario y la

información. Esto permite que el usuario acceda a los datos de modo interactivo, gracias


- 14 -

MARCO TEÓRICO

a que la página responderá a cada una de sus acciones, como por ejemplo rellenar y

enviar formularios, participar en juegos diversos y acceder a gestores de base de datos

de todo tipo.

2.5.1. ANTECEDENTES

En los primeros tiempos de la computación cliente-servidor, cada aplicación tenía

su propio programa cliente que servía como interfaz de usuario que tenía que ser

instalado por separado en cada ordenador personal de cada usuario. El cliente realizaba

peticiones a otro programa -el servidor- que le daba respuesta. Una mejora en el

servidor, como parte de la aplicación, requería normalmente una mejora de los clientes

instalados en cada ordenador personal, añadiendo un coste de soporte técnico y

disminuyendo la productividad.

A diferencia de lo anterior, las aplicaciones web generan dinámicamente una serie

de páginas en un formato estándar, como HTML o XHTML, soportados por los

navegadores web comunes. Se utilizan lenguajes interpretados en el lado del cliente,

directamente o a través de plugins tales como JavaScript, Java, Flash, etc., para añadir

elementos dinámicos a la interfaz de usuario. Generalmente cada página web en

particular se envía al cliente como un documento estático, pero la secuencia de páginas

ofrece al usuario una experiencia interactiva. Durante la sesión, el navegador web

interpreta y muestra en pantalla las páginas, actuando como cliente para cualquier

aplicación web.

El desarrollo de aplicaciones WEB ha evolucionado por los siguientes aspectos:

Evolución del Uso/Demandas

Evolución de Tecnologías Navegador

Evolución Tecnologías Servidores

Marketing de Ventas

Hiper-Hype y las Dot.Com

2.5.2. CONSIDERACIONES TECNICAS

Una ventaja significativa es que las aplicaciones web deberían funcionar igual

independientemente de la versión del sistema operativo instalado en el cliente. En vez

de crear clientes para Windows, Mac OS X, GNU/Linux y otros sistemas operativos, la

aplicación web se escribe una vez y se ejecuta igual en todas partes. Sin embargo, hay

aplicaciones inconsistentes escritas con HTML, CSS, DOM y otras especificaciones

estándar para navegadores web que pueden causar problemas en el desarrollo y soporte

de estas aplicaciones, principalmente debido a la falta de adhesión de los navegadores a

dichos estándares web (especialmente versiones de Internet Explorer anteriores a la

7.0). Adicionalmente, la posibilidad de los usuarios de personalizar muchas de las

características de la interfaz (tamaño y color de fuentes, tipos de fuentes, inhabilitar

Javascript) puede interferir con la consistencia de la aplicación web.

Otra aproximación es utilizar Adobe Flash Player o Java applets para desarrollar

parte o toda la interfaz de usuario. Como casi todos los navegadores incluyen soporte

para estas tecnologías (usualmente por medio de plug-ins), las aplicaciones basadas en

Flash o Java pueden ser implementadas con aproximadamente la misma facilidad. Dado


- 15 -

MARCO TEÓRICO

que ignoran las configuraciones de los navegadores, estas tecnologías permiten más

control sobre la interfaz, aunque las incompatibilidades entre implementaciones Flash o

Java puedan crear nuevas complicaciones, debido a que no son estándares. Por las

similitudes con una arquitectura cliente-servidor, con un cliente "no ligero", existen

discrepancias sobre el hecho de llamar a estos sistemas “aplicaciones web”; un término

alternativo es “Aplicación Enriquecida de Internet”.

2.5.3. ESTRUCTURA DE APLICACIONES WEB

Aunque existen muchas variaciones posibles, una aplicación web está normalmente

estructurada como una aplicación de tres-capas. En su forma más común, el navegador

web ofrece la primera capa, y un motor capaz de usar alguna tecnología web dinámica

(ejemplo: PHP, Java Servlets o ASP, ASP.NET, CGI, ColdFusion, embPerl, Python

(programming language) o Ruby on Rails) que constituye la capa intermedia. Por

último, una base de datos constituye la tercera y última capa.

El navegador web manda peticiones a la capa intermedia que ofrece servicios

valiéndose de consultas y actualizaciones a la base de datos y a su vez proporciona una

interfaz de usuario.

2.5.4. VENTAJAS Y DESVENTAJAS

VENTAJAS

1. Ahorra tiempo: Se pueden realizar tareas sencillas sin necesidad de descargar ni

instalar ningún programa.

2. No hay problemas de compatibilidad: Basta tener un navegador actualizado para

poder utilizarlas.

3. No ocupan espacio en nuestro disco duro.

4. Actualizaciones inmediatas: Como el software lo gestiona el propio

desarrollador, cuando nos conectamos estamos usando siempre la última versión

que haya lanzado.

5. Consumo de recursos bajo: Dado que toda (o gran parte) de la aplicación no se

encuentra en nuestro ordenador, muchas de las tareas que realiza el software no

consumen recursos nuestros porque se realizan desde otro ordenador.

6. Multiplataforma: Se pueden usar desde cualquier sistema operativo porque sólo

es necesario tener un navegador.

7. Portables: Es independiente del ordenador donde se utilice (un PC de sobremesa,

un portátil...) porque se accede a través de una página web (sólo es necesario

disponer de acceso a Internet). La reciente tendencia al acceso a las aplicaciones

web a través de teléfonos móviles requiere sin embargo un diseño específico de

los ficheros CSS para no dificultar el acceso de estos usuarios.

8. La disponibilidad suele ser alta porque el servicio se ofrece desde múltiples

localizaciones para asegurar la continuidad del mismo.

9. Los virus no dañan los datos porque éstos están guardados en el servidor de la

aplicación.

10. Colaboración: Gracias a que el acceso al servicio se realiza desde una única

ubicación es sencillo el acceso y compartición de datos por parte de varios


- 16 -

MARCO TEÓRICO

usuarios. Tiene mucho sentido, por ejemplo, en aplicaciones online de

calendarios u oficina.

11. Los navegadores ofrecen cada vez más y mejores funcionalidades para crear

aplicaciones web ricas (RIAs).

DESVENTAJAS

1. Habitualmente ofrecen menos funcionalidades que las aplicaciones de escritorio.

Se debe a que las funcionalidades que se pueden realizar desde un navegador

son más limitadas que las que se pueden realizar desde el sistema operativo.

Pero cada vez los navegadores están más preparados para mejorar en este

aspecto. La aparición de HTML 5 representa un hito en este sentido. Es posible

añadir funcionalidades a estas aplicaciones gracias al uso de Aplicaciones de

Internet Ricas.

2. La disponibilidad depende de un tercero, el proveedor de la conexión a internet o

el que provee el enlace entre el servidor de la aplicación y el cliente. Así que la

disponibilidad del servicio está supeditada al proveedor

2.6. PROGRAMACION WEB

La programación Web, parte de las siglas WWW, que significan World Wide Web

o telaraña mundial.

Para realizar una página con la programación Web, se deben tener claros, tres

conceptos fundamentales los cuales son, el URL(Uniform Resource Locators), es un

sistema con el cual se localiza un recurso dentro de la red, este recurso puede ser una

página web, un servicio o cualquier otra cosa. En resumen el URL no es más que un

nombre, que identifica una computadora, dentro de esa computadora un archivo que

indica el camino al recurso que se solicita.

El siguiente concepto dentro de la programación Web, es el protocolo encargado de

llevar la información que contiene una pagina Web por toda la red de internet, como es

el HTTP (Hypertext Transfer Protocol).

Y por último el lenguaje necesario cuya funcionalidad es la de representar cualquier

clase de información que se encuentre almacenada en una pagina Web, este lenguaje es

el HTML (Hypertext Markup Language).

En la programación Web, el HTML es el lenguaje que permite codificar o preparar

documentos de hipertexto, que viene a ser el lenguaje común para la construcción de

una página Web.

Con el comienzo de Internet y la programación web, se desfasaron los diseños

gráficos tradicionales, con lo que se empezaron a diseñar interfaces concretas para este

medio, buscando ficheros pequeños para facilitar la carga de los mismos. La

programación web se orientaba a un diseño muy cargado interactuando con el usuario,


- 17 -

MARCO TEÓRICO

mientras que al empezar a competir con millones de webs se ha optado más por el

diseño sencillo y de fácil comprensión.

En programación web se creó la necesidad de conocer a fondo diferentes lenguajes

de programación como HTML, JavaScript y DHTML. Con esto se creó un nuevo

profesional de la informática, el diseñador web, experto en estos menesteres, que viene

siendo algo así como un experto en programación web, algo entre diseñador gráfico

tradicional y el programador de aplicaciones llevadas a Internet.

2.7. PARADIGMA DE LA PROGRAMACION

Un paradigma de programación es una propuesta tecnológica que es adoptada por

una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que

unívocamente trata de resolver uno o varios problemas claramente delimitados. La

resolución de estos problemas debe suponer consecuentemente un avance significativo

en al menos un parámetro que afecte a la ingeniería de software. Tiene una estrecha

relación con la formalización de determinados lenguajes en su momento de definición.

Probablemente el paradigma de programación que actualmente es el más usado a

todos los niveles es la orientación a objeto. El núcleo central de este paradigma es la

unión de datos y procesamiento en una entidad llamada "objeto", relacionable a su vez

con otras entidades "objeto". Tradicionalmente datos y procesamiento se han separado

en áreas diferente del diseño y la implementación de software. Esto provocó que

grandes desarrollos tuvieran problemas de fiabilidad, mantenimiento, adaptación a los

cambios y escalabilidad. Con la orientación a objetos y características como el

encapsulado, polimorfismo o la herencia se permitió un avance significativo en el

desarrollo de software a cualquier escala de producción.

2.8. CLIENTE-SERVIDOR

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro

programa (el servidor) que le da respuesta. 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.

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. 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.

http://es.wikipedia.org/wiki/Servidor

http://es.wikipedia.org/wiki/Cliente_(inform%C3%A1tica)



http://es.wikipedia.org/wiki/Web

http://es.wikipedia.org/wiki/Computador


- 18 -

MARCO TEÓRICO

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 esté utilizando en una red mixta.

2.9. SSL

Secure Sockets Layer (SSL; en español «capa de conexión segura») y su

sucesor Transport Layer Security (TLS; en español «seguridad de la capa de

transporte») son protocolos criptográficos que proporcionan

comunicaciones seguras por una red, comúnmente Internet.

Descripción

SSL proporciona autenticación y privacidad de la información entre extremos

sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es

autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin

autenticar.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación

Intercambio de claves públicas y autenticación basada en certificados

digitales

Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos

se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital

Signature Algorithm) o Fortezza;

Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption

Algorithm), DES (Data Encryption Standard), Triple DES yAES (Advanced

Encryption Standard);

Con funciones hash: MD5 o de la familia SHA.

Funcionamiento:

El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser

comprimido, cifrado y empaquetado con un código de autenticación del

mensaje (MAC). Cada registro tiene un campo de content_type que especifica el

protocolo de nivel superior que se está usando.

Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el

protocolo handshake, que tiene el content_type 22.

El cliente envía y recibe varias estructuras handshake:


- 19 -

MARCO TEÓRICO

Envía un mensaje ClientHello especificando una lista de conjunto de

cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida.

Éste también envía bytes aleatorios que serán usados más tarde

(llamados Challenge de Cliente o Reto). Además puede incluir el identificador de la

sesión.

Después, recibe un registro ServerHello, en el que el servidor elige los

parámetros de conexión a partir de las opciones ofertadas con anterioridad por el

cliente.

Cuando los parámetros de la conexión son conocidos, cliente y servidor

intercambian certificados (dependiendo de las claves públicas de cifrado

seleccionadas). Estos certificados son actualmente X.509, pero hay también un

borrador especificando el uso de certificados basados en OpenPGP.

Cliente y servidor negocian una clave secreta (simétrica) común llamada master

secret, posiblemente usando el resultado de un intercambio Diffie-Hellman, o

simplemente cifrando una clave secreta con una clave pública que es descifrada con

la clave privada de cada uno. Todos los datos de claves restantes son derivados a

partir de este master secret (y los valores aleatorios generados en el cliente y el

servidor), que son pasados a través una función pseudoaleatoria cuidadosamente

elegida.

Aplicaciones

SSL se ejecuta en una capa entre los protocolos de aplicación

como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de

la familia de protocolos TCP/IP.

HTTPS es usado para asegurar páginas World Wide Web para aplicaciones de comercio

electrónico, utilizando certificados de clave pública para verificar la identidad de los

extremos.

SSL también puede ser usado para tunelizar una red completa y crear una red privada

virtual (VPN), como en el caso de OpenVPN.

2.10. SEGURIDAD WEB

La seguridad, en informática como en otras áreas, se basa en la protección de

activos. Estos activos pueden ser elementos tan tangibles como un servidor o una base

de datos, o pueden ser la reputación de una empresa. Generalmente podemos evaluar la

seguridad de un activo en base a tres aspectos principales que no necesitan explicación:

integridad, disponibilidad, confidencialidad.

Estos tres aspectos a su vez dependen de otros tres elementos principales que

engloban prácticamente todos los distintos controles que se pueden establecer en un

sistema informático:


- 20 -

MARCO TEÓRICO

Autenticación: los clientes de nuestras aplicaciones o servicios deben ser

identificados de forma única, sean usuarios finales, otros servicios o

computadoras externas.

Autorización: no solo es necesario saber quienes acceden a nuestros activos,

también es necesario establecer que es lo que pueden hacer con ellos. Un nivel

de autorización dado determina que tipo de operaciones o transacciones puede

efectuar un cliente dado sobre un recurso dado.

Registro y Auditoria: luego de efectuada una operación, es importante que esta

sea registrada adecuadamente, en particular es esencial si queremos evitar el

repudio de transacciones efectuada por un cliente.

Todos estos conceptos son especialmente válidos en el entorno de Internet, y

particularmente importantes dado el crecimiento explosivo de los servicios y

aplicaciones accesibles a través de Internet. Si bien cuando se habla de la seguridad de

aplicaciones web se deben considerar no sólo las amenazas externas a la compañía o

institución sino también las internas (administradores malintencionados, usuarios que

provocan accidentes, etc), las externas, generalmente son las más peligrosas e

impredecibles. Es sabido por otro lado que las aplicaciones más robustas y resistentes a

ataques son aquellas en las cuales las cuestiones de seguridad fueron consideradas desde

las primeras etapas del desarrollo.

2.11. RIESGOS DEL ENTORNO WEB

Se ha comprobado que en los últimos años, 75% o más de los ataques electrónicos

fueron a nivel de aplicación (y no a nivel de host o de red).

2.11.1. BLANCOS ATRACTIVOS

Todo tipo de transacciones se realizan actualmente en la web, y cada vez en mayor

proporción. Detalles de cuentas bancarias, tarjetas de crédito y todo tipo de información

confidencial y de valor circulan en enormes cantidades y continuamente. Es por ende

lógico que la mayoría de los esfuerzos de hackers y demás atacantes se centre en

vulnerar estas aplicaciones.

2.11.2. PRESIONES DE NEGOCIO

La variedad y complejidad de los requerimientos de usuarios finales continúa

creciendo, y con ellos aumenta la complejidad de las aplicaciones, la cantidad de

funcionalidades y fases de testeo. Esto sumado al incremento en la competencia y en la

necesidad de superarla en el time-to-market, implican sacrificios importantes en los

aspectos no-funcionales de la aplicación y específicamente en los aspectos de seguridad.

Especialmente cuando no existe una conciencia de seguridad a nivel corporativo, se

tiende a generar una alta presión para terminar el trabajo sin considerar suficientemente

las posibles vulnerabilidades.


- 21 -

MARCO TEÓRICO

2.11.3. DEBILIDADES DE HTTP

Las aplicaciones web están en parte definidas por su uso del protocolo HTTP como

medio de comunicación entre cliente y servidor. Este protocolo es simple y basado en

ASCII por lo que no se requiere gran esfuerzo para generar pedidos y descifrar el

contenido de las respuestas. Además utiliza un puerto TCP tan conocido que de poco

sirve un firewall para proteger una aplicación si tiene que admitir el tráfico a través del

puerto 80.

No mantiene por sí mismo el estado de la sesión ya un atacante no tiene que emular

mecanismos de mantenimiento de sesión, basta con emitir un request para lograr el

cometido. Mecanismos como el uso de cookies permiten simular una sesión virtual

intercambiando información adicional en cada request/response, pero no son efectivas si

no se las implementa bien, e introducen problemas adicionales de seguridad y

privacidad.

Existen muchas excepciones y variantes adicionales a estos elementos; en particular

se utiliza ampliamente SSL como protocolo de encriptación a nivel de transporte en las

comunicaciones cliente-servidor.

2.11.4. MITOS DE LA SEGURIDAD WEB

El usuario solamente enviará entradas esperadas: HTML admite el uso de tags que

manipulan las entradas a la aplicación, por ejemplo si la aplicación utiliza campos

ocultos para enviar información sensible estos pueden ser fácilmente manipulados desde

el cliente.

La validación puede realizarse únicamente del lado del cliente con JavaScript: Si no

se efectúa ninguna validación del lado del servidor, cualquier atacante que evite esta

validación, lo que no es difícil de lograr, tendrá acceso total a toda la aplicación.

El uso de firewalls es suficiente: Si el firewall tiene que habilitar los puertos 80 y/o

443 para que la aplicación sea accesible al exterior, no podrá hacer nada para detectar

entradas maliciosas del cliente, y por supuesto no es protección contra ataques internos.

El uso de SSL es una solución suficiente: SSL simplemente cubre el

request/response HTTP dificultando la intercepción del tráfico entre cliente y servidor,

pero no agrega seguridad al servidor ni evita el envío de código malicioso desde el

cliente.

2.11.5. AMENZAS COMUNES

Los múltiples ataques externos a los que puede estar expuesto un sitio web son

usualmente clasificados en 6 categorías principales. Indicaremos cada una y los tipos de

ataques más típicos que incluyen, y a continuación describiremos en mayor detalle

cuatro de ellos.


- 22 -

MARCO TEÓRICO

1) Autenticación: son las que explotan el método de validación de la identidad de un

usuario, servicio o aplicación

Fuerza Bruta

Autenticación insuficiente

Débil validación de recuperación de Password

2) Autorización: explotan el mecanismo de un sitio web de determinar si un usuario o

servicio tiene los permisos necesarios para ejecutar una acción.

Predicción de Credenciales o Sesión

Autorización insuficiente

Expiración de Sesión insuficiente

Fijado de Sesión

3) Ataques Lógicos: explotan la lógica de la aplicación (el flujo procedural utilizado

por la aplicación para efectuar cierta acción.

Abuso de funcionalidad

Denial of Service

Insuficiente Anti-Automatismo

Insuficiente validación de procesos

Manipulación de entradas (URL, campos)

4) Ataques al cliente: atacan al usuario de la aplicación.

Content Spoofing

Cross-Site Scripting

5) Ejecución de comandos: ataques diseñados para ejecutar comandos remotos en el

servidor.

Buffer Overflow

Format String

LDAP Injection

Ejecucuón de Comandos (OS Commanding)

SQL Injection

SSI Injection

XPath Injection

6) Robo de Información: ataques que apuntan a adquirir información específica sobre

el sitio web.

Indexado de directorio

Caminos transversales

Predicción de ubicación de recursos

Escape de información

2.11.6. DESCRIPCION DE ALGUNOS ATAQUES

SQL Injection

SQL Injection es una vulnerabilidad que afecta aplicaciones a nivel de base de

datos. Dicha vulnerabilidad consiste en enviar instrucciones SQL adicionales a partir de

parámetros entrada ingresados por el usuario.


- 23 -

MARCO TEÓRICO

Al "inyectar" el código SQL malicioso dentro de estos campos, el código "invasor"

se ejecuta dentro del código SQL propio de la aplicación para alterar su funcionamiento

normal, de acuerdo con el propósito del atacante.

SQL Injection es un problema de seguridad que debe ser tomado en cuenta por el

programador para prevenirlo. La vulnerabilidad ocurre cuando la aplicación ejecuta una

sentencia SQL que utiliza el valor de campos de entrada sin validarlos correctamente.

Permiten al atacante saltar restricciones de acceso, elevar privilegios del usuario,

extracción de información de la base de datos, ejecución de comandos dentro del

servidor. Incluso es posible destruir parte la base de datos de la aplicación (por ejemplo

insertando una sentencia DropTable).

Contramedidas

Los riesgos de SQL Injection pueden superarse relativamente fácil con cambios de

programación simples, que sin embargo requieren considerable disciplina de los

programadores para aplicar los métodos siguientes para cada procedimiento y función

accesibles de la red.

Variables de alcance: La más poderosa protección contra el SQL Injection es

utilizar solamente variables de alcance para imposibilitar la concatenación de

instrucciones SQL donde puedan aplicarse variables en las instrucciones anexadas.

Validación de la entrada: es necesaria una validación fuerte en lado de servidor para

entrada de usuario, validación de datos filtrar la entrada del usuario de caracteres SQL,

verificar tanto el tamaño como el tipo de los datos y sintaxis de las entradas de usuario.

Este punto se aplica a muchos ataques similares, en particular lo reafirmaremos para los

próximos ataques analizados.

Mensajes de error: Los mensajes de error a menudo revelan demasiada información

que puede ser útil al atacante (nombres de tablas, campos, vistas); por lo tanto no se

deberá exponer al usuario final los mensajes de error devueltos por el gestor de la base

de datos. Los mensajes de errores de la base de datos deberían ser notificados solamente

a los administradores de la aplicación.

Manipulación de parámetros

Es un conjunto de técnicas que atacan la lógica de negocio de la aplicación,

tomando ventaja del uso de campos ocultos o fijos para la transferencia de información

sensible entre browser y servidor. En particular, tags ocultos en un form, cookies o

parámetros anexados a la URL son fácilmente modificables por un atacante.

Manipulación de campos ocultos

Cualquiera de los valores que se almacenan en los campos de un formpueden ser

manipulados por un atacante. En particular los campos ocultos son usualmente

atractivos para su manipulación ya que muchos desarrolladores los utilizan para

información confidencial de estatus de algún objeto sobre el que se está trabajando.

La manipulación de estos campos es tan simple como salvar la página, editar el

valor de estos campos en su código HTML y recargarla en el browser.


- 24 -

MARCO TEÓRICO

Manipulación de URL

Los forms HTML envían sus resultados usando uno de dos métodos posibles: GET

o POST. Si el método es GET, todos los parámetros del form y sus valores

correspondientes aparecen en cadena de búsqueda del siguiente URL que el usuario ve.

Esta cadena puede ser fácilmente manipulable

Existen otros parámetros URL que podrian ser modificados, tales como atributos y

módulos internos. Los atributos son parámetros únicos que caracterizan el

comportamiento de la página que se envía. Un usuario malicioso puede modificar el

parámetro mode a readwrite para obtener permisos indebidos sobre el contenido.

Ejecución de comandos

Las técnicas de manipulación de entrada vistas son sólo algunas que llevan a la

posibilidad de ejecutar remotamente comandos del Sistema Operativo de la víctima.

Determinados caracteres especiales pueden ser interpretados por scripts de

validación poco seguros como una instrucción al SO de esperar un comando arbitrario a

continuación. En particular, el punto y coma o la barra | son en Unix caracteres que

permiten encadenar comandos. Por tanto incluir en el campo de entrada un ; seguido del

comando que se desea ejecutar puede tener éxito si el mecanismo de validación no es lo

bastante robusto.

Contramedidas

En la mayoría de los ataques de inyección de comandos, es necesario tener

conciencia de que todo dato hacia y desde un browser puede ser modificado. Por ende,

la validación propiamente dicha de cada dato de entrada debe darse en el servidor, fuera

del control del usuario.

Adicionalmente el servidor debería además configurarse para requerir una

autenticación debida al nivel del directorio para cada archivo en el mismo. Aún así esta

solución no es perfecta, por lo que es conveniente que el usuario utilizado por la

aplicación sobre el servidor tenga los permisos mínimos necesarios, para minimizar el

posible impacto.

Cross Site Scripting (XSS).

Esta amenaza surge de los riesgos inherentes de permitir a un servidor web enviar

código ejecutable (en cualquier lenguaje de scripting embebido en HTML) a un

browser. Cuando a un script de una página se le permite acceder a datos de otra página u

objeto, existe la posibilidad de que un sitio web malicioso, lo utilice para obtener

información confidencial.

El crosssite scripting, aprovecha las vulnerabilidades en los mecanismos de

validación de interacción entre páginas y objetos y en lenguajes scripting que ejecutan

en el cliente.

Existe tres tipos conocidos que vulnerabilidades que implican

Tipo 1 – XSS local


- 25 -

MARCO TEÓRICO

En esta categoría el problema reside en el propio script del lado del ciente de la

página. Por ejemplo si un fragmento de JavaScript accede un parámetro de un request

HTML y lo utiliza para escribir HTML en su propia página, no codificándolo como

entidades HTML, se presenta la vulnerabilidad. Estos datos serán reinterpretados por los

browsers como HTML, que podría incluir código adicional (maligno).

Tipo 2 – XSS reflejado

Este es el tipo más común, también es conocido como no-persistente. La

vulnerabilidad se presenta cuando los datos provistos por el cliente es utilizada

inmediatamente por scripts del lado del servidor para generar la página de resultados. Si

datos no validados provistos por el cliente son incluidos en la página de resultados sin

una codificación apropiada, es posible insertar código desde el lado del cliente. Basta

con un poco de ingeniería social para llevar a un usuario desprevenido a seguir un link

malicioso que inserte este código en la página de resultados, obteniendo acceso total a

su contenido.

Tipo 3 – XSS persistente

Este tipo incluye los ataques más poderosos. La vulnerabilidad existe cuando los

datos provistos por el cliente a la aplicación son almacenados persistentemente en el

servidor, y accesible a varios usuarios del sitio sin codificación de entidades HTML –

por ejemplo messageboards. El atacante puede insertar un script una única vez, y con

esto le basta para alcanzar a un gran número de usuarios, sin requerir mucho esfuerzo de

ingeniería social. Los métodos de inserción son variados y no es necesario utilizar la

aplicación misma para explotar la vulnerabilidad.

Ejemplo de cada uno de los tipos mencionados anteriormente.

Ejemplo1 – XSS local

Atacante envía a usuario, via email u otro mecanismo, la URL de una página

fraudulenta. Usuario cliquea en el link, un código JavaScript en la página abre una

página HTML vulnerable local a la máquina del usuario. La página HTML es obligada

a ejecutar código JavaScript en la localidad de la máquina del usuario, el atacante puede

ahora ejecutar comandos en la máquina del usuario con los permisos de éste.

Ejemplo 2 – XSS reflejado

El usuario visita frecuentemente un website particular. El servidor de este sitio le

permite al usuario loguearse con un ID/pswd propio y almacena información

confidencial (tarjeta de crédito). El atacante verifica una vulnerabilidad de XSS

reflejada en el servidor. El atacante genera una URL y la envía al usuario simulando ser

el servidor del sitio (mediante spoofing). El usuario visita esta URL estando logueado

en el servidor. Un script maligno embebido en la URL se ejecuta en el browser del

usuario tal como si proviniera del servidor, obteniendo información confidencial del

usuario y enviandola al servidor web del atacante.

Ejemplo 3 – XSS persistente

El servidor de un sitio web permite a sus usuarios publicar mensajes y otros

contenidos en el mismo para acceso de otros miembros. El atacante detecta una

vulnerabilidad de XSS persistente en el servidor. El atacante postea un mensaje con un

script insertado, asegurándose que muchos otros usuarios del sitio querrán leerlo por

cualquier motivo. Mediante el simple acceso al mensaje, el script insertado puede hacer


- 26 -

MARCO TEÓRICO

que cookies de sesión u otra información de autenticación podría enviarse al servidor

web del atacante. El atacante podria ahora loguearse como otros usuarios al sitio

Contramedidas

Preferentemente no debería permitirse código HTML en los campos de entrada, en caso

de que se necesitara, deberían de validarse los tags, descartando aquellos que pudieran

ser peligrosos, adicionalmente también se deben descartar caracteres potencialmente

peligrosos como -,",",?,&,<,>,etc.


- 27 -

METODOLOGÍA DE TRABAJO


3.1. MÉTODOS

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un

tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un

periodo mucho mayor.

Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de

construir un sistema de software hasta que este es retirado, se identifican varias etapas

que en conjunto se denominan el ciclo de vida del software y en cada caso, en función

de cuales sean las características del proyecto, se configurará el ciclo de vida de forma

diferente.

Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño

del sistema, implementación del software, aplicación y pruebas, entrega y

mantenimiento.

Un aspecto esencial dentro de las tareas del desarrollo del software es la

documentación de todos los elementos y especificaciones en cada fase. Dado que esta

tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma

distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su

importancia en el conjunto del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de

vida son:

Análisis: Construye un modelo de los requisitos.

Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la

estructura en la que descompone el sistema y la interfaz de usuario.

Codificación: Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura

que el sistema siga funcionando y adaptándose a nuevos requisitos.

Las etapas constan de tareas. La documentación es una tarea importante que se

realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos

procedentes de las etapas anteriores y produce otros documentos de salida.


- 28 -


3.2. CICLO DE VIDA

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el

software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los

propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90%

de los sistemas han sido desarrollados así).

3.3. CICLO DE VIDA EN CASCADA

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las

modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad

de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la

codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que

volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el

resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la

siguiente. Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es

un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo

diferente gracias a la documentación generada entre las fases.

Los documentos son:

Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el

cliente. Produce el S.R.D. (Software Requirements Document).

Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)

Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también

pruebas de unidad.

Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el

sistema. El resultado de las pruebas es el producto final listo para entregar.

Ventajas

o La planificación es sencilla.

o La calidad del producto resultante es alta.

o Permite trabajar con personal poco cualificado.

Desventajas

o Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que

el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede

ser que surjan necesidades imprevistas.

o Si se han cometido errores en una fase es difícil volver atrás.

No se tiene el producto hasta el final, esto quiere decir que:

o Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el

consiguiente gasto inútil de recursos.

o El cliente no verá resultados hasta el final, con lo que puede impacientarse.

o No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).

o Es comparativamente más lento que los demás y el coste es mayor también.


- 29 -


3.4. ETAPAS DEL MODELO EN CASCADA

3.4.1. ANALISIS DE REQUERIMIENTOS

En esta fase se analizan las necesidades de los usuarios finales del software para

determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD

(documento de especificación de requisitos), que contiene la especificación completa de

lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere

del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir

nuevos resultados a mitad del proceso de elaboración del software.

3.4.2. DISEÑO DEL SISTEMA

Se descompone y organiza el sistema en elementos que puedan elaborarse por

separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el

SDD (Documento de Diseño del Software), que contiene la descripción de la estructura

relacional global del sistema y la especificación de lo que debe hacer cada una de sus

partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño

detallado. El primero de ellos tiene como objetivo definir la estructura de la solución

(una vez que la fase de análisis ha descrito el problema) identificando grandes módulos

(conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define

la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la

organización del código para comenzar la implementación.

3.4.3. DISEÑO DEL PROGRAMA

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de

los requerimientos del usuario así como también los análisis necesarios para saber que

herramientas usar en la etapa de Codificación.

3.4.4. CODIFICACION O PROGRAMACION

Es la fase de programación o implementación propiamente dicha. Aquí se

implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos

para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y

componentes reutilizables dentro del mismo proyecto para hacer que la programación

sea un proceso mucho más rápido.

3.4.5. PRUEBAS

Los elementos, ya programados, se ensamblan para componer el sistema y se

comprueba que funciona correctamente y que cumple con los requisitos, antes de ser

puesto en funcionamiento.


- 30 -

ANALISIS DEL SISTEMA

ANALISIS DEL SITEMAS

4.1. ESPECIFICACIÓN DE REQUISITOS SOFTWARE

4.1.1. INTRODUCCION

Propósito

Con el propósito de presentar todas las funcionalidades y capacidades que tendrá el

Sistema de Gestión Académica, se ha redactado el presente documento.

Ámbito del Sistema

El Sistema de Gestión Académica tendrá por nombre SAGAT (Sistema

Automatizado de Gestión Académica Theotokos), este sistema registrará información

de los estudiantes a través del proceso de matricula así como de los docentes que se

encuentren actualmente laborando.

Se llevará un registro de las notas de los estudiantes permitiendo el fácil acceso a

estas y otras informaciones de relevancia académica a los mismos estudiantes como

también a los docentes.

Se hará posible la publicación de noticias y avisos de eventos que acontecen en la

vida estudiantil además de información del mismo centro educativo.

El sistema no pretende gestionar la distribución de becas ni horarios de clases; así

tampoco la impresión de ciertos informes como el de Retención de Estudiantes,

Aprobados y Reprobados y el de Rendimiento Académico los cuales son actualmente

manejados por secretaría.

Personal Involucrado

El personal que podrá interactuar con el sistema está compuesto por la Directora,

Secretaria, Administrador del sistema, Docente y Alumno, todos y cada uno con

diferentes privilegios y funciones.

Definiciones, Acrónimos y Abreviaturas

CMML: Colegio Madre María Luis, centro educativo al cual está dirigido el sistema de

gestión académica.

SAGAT: Sistema Automatizado de Gestión Académica THEOTOKOS.

BBDD: Base de Datos.


- 31 -


Referencias

IEEE Std 610.12-1990. Software Engineering Standards Committee of the IEEE

Computer Society

IEEE Std 830-1998. Software Engineering Standards Committee of the IEEE Computer

Society

Resumen

En las siguientes secciones del documento se describe de forma general lo que se

espera del producto, sus funciones, las características que deben poseer los usuarios del

producto, las limitaciones bajo las que el producto no podría funcionar correctamente

y/o eficientemente, algunos requisitos a futuro. También de manera más específica se

describe la interfaz que tendrá el producto, atributos que deberá tener el sistema sobre

el cual funcionará, requisitos para el rendimiento y otros requisitos.

4.1.2. DESCRIPCIÓN GENERAL

Perspectiva del Producto

SAGAT es el primer proyecto software en su clase en ser utilizado para la gestión

académica en el CMML.

Funcionalidad del Producto

SAGAT permitirá el registro de estudiantes a través de el proceso de matrícula, se

llevara además un registro de las notas la cuales van a poder ser consultadas en línea por

ellos mismo. Se guardaran los datos de cada docente que se encuentre en funciones

dentro del CMML.

Se brindara fácil acceso a la información referente al CMML y a sus actividades

académicas y recreativas las cuales se podrán mantener actualizadas por la gestión de la

secretaría y dirección del CMML.

Características de los Usuarios

Los usuarios de SAGAT deberán tener conocimientos básicos en el manejo y uso de

un computador así como del navegador a través del cual van a consultar al sistema.

Adicionalmente los administradores de SAGAT en este caso Directora y Secretaria

deberán tener nociones de informática que les faciliten el llenado de los formularios

para el registro de estudiantes.


- 32 -


Restricciones

Políticas de la Empresa

La administración del CMML solamente permitirá contenido de carácter educativo,

académico y cultural que puedan contribuir al buen desarrollo y desenvolvimiento de la

vida estudiantil. Además estará a discreción de la misma administración la publicación

de eventos o reuniones de recreación organizadas por y para estudiantes del centro.

Limitaciones de Hardware

El computador que tendrá la función de servidor web deberá cumplir con las

siguientes características mínimas:

3 Gb de RAM

160Gb de Disco Duro

Procesador Intel CoreDuo 2.0 Ghz

Tarjeta de Red

Al menos una terminal o cliente con las siguientes características mínimas:

521 Mb de RAM

40 Gb de Disco Duro

Procesador Intel Pentium IV 2.0 Ghz

Tarjeta de Red

Lenguajes de Programación

PHP 5.0

Flash, Action Script 3.0

Javascript

Sql

Protocolos de Comunicación

HTTP 1.1

Consideraciones de Seguridad

SAGAT mantendrá la integridad de los datos además de asegurar la protección de

los mismos ante posibles modificaciones por parte de usuarios no autorizados.

Suposiciones y Dependencias

Se da por sentado que el servidor web trabajará bajo el Sistema Operativo Linux.

Evolución previsible del sistema

En un futuro los estudiantes serán capaces de matricularse en línea y de esta manera

el proceso se hará más rápido y con mayor comodidad para los padres y los mismos

alumnos.

Se podría desarrollar por separado un sistema contable completo que trabajará en

conjunto con SAGAT para manejar la solvencia de los alumnos.


- 33 -


Con el fin de ayudar a los padres de familia muy ocupados se podría llegar a

implementar los pagos en línea con el propósito de no hacer perder tiempo preciado en

grandes colas.

4.2. REQUISITOS ESPECIFICOS

4.2.1. REQUISITOS COMUNES DE INTERFACES

Interfaces de Usuario

Como cualquier aplicación típica WEB el sistema constará con una interfaces de

usuario compuesta por formularios, menús, botones, cajas de texto, etc.

Se presentarán gráficos en caso de ser necesario con el objetivo de explicar mejor

resultados de consultas relacionadas con rendimiento. La introducción de datos se hará

mayormente por medio de cajas de texto o por selección de opciones.

La interfaz será amigable e intuitiva, para mejorar la experiencia del usuario con el

sistema.

Interfaces de Hardware

El Computador donde estará instalado el sistema deberá constar con una tarjeta de

red un mínimo de 3 Gb de RAM, 120Gb de Disco duro y un procesador Intel Dual core

a 2.0

Interfaces de Software

Se deberá constar con una base de datos MySql.

Interfaces de Comunicación

Se deberá constar con todos los protocolos de red necesarios para la comunicación

entre el servidor y las terminales, además un navegador web compatible.


- 34 -


4.2.2. REQUISITOS FUNCIONALES

RF 1 Matricular Alumno

Introducción:

Este proceso deberá capturar todos los datos del futuro alumno para que su registro sea

incorporado al resto del cuerpo estudiantil.

Entradas:

Por Pantalla:

Nombre del Alumno

Apellido del Alumno

Fecha de Nacimiento (aa-mm-dd)

Cedula del Alumno

Selección del sexo del alumno

Año Académico

Selección de la religión que profesa

Nombre del padre

Apellido del padre

Cedula del padre

Trabaja (Selección de opción: Si o No.)

Oficio del padre

Lugar de Trabajo

Teléfono del padre

Nombre de la madre

Apellido de la madre

Cedula de la madre

Trabaja (Selección de opción: Si o No.)

Oficio de la madre

Lugar de Trabajo

Teléfono de la madre

Procesos:

Se ingresaran todos los datos en el formulario, se validarán los datos para

comprobar que cumplan con el formato y se guardaran los datos del alumno.

Salida:

Una vez almacenados los datos mostrará mensaje Matriculado con Éxito.


- 35 -


RF 2 Rematricular Alumno

Introducción:

Este proceso actualizará el grado del alumno y cualquier dato que necesite ser cambiado

si la información actual no coincide con la del año anterior.

Entradas:

Por Pantalla:

Numero de Carnet del Alumno

Por Sistema:

Cundo el sistema consulte los datos del alumno con el Numero de Carnet

brindara estos datos al proceso.

Procesos:

Se solicitará el Numero de Carnet del alumno, se hará las búsqueda de la

información del estudiante, se cargaran en pantalla los datos que se ingresaron

en el momento de la matricula y se podrá editar dicha información.

Salida:

Una vez que se valide que los campos cumplen con el formato, si el estudiante

fue matriculado en el mismo año no se guardaran los cambios y el sistema

solicitara ingresar nuevamente el número del carnet, los datos editados en este

proceso solo se guardarán si el sistema comprueba que no se había matriculado

el alumno en el mismo año.

RF 3 Actualizar Datos Alumnos

Introducción:

En esta función se podrán editar los datos de los alumnos previamente matriculado para

corregir cualquier error cometido en el proceso de matrícula o para actualizar algún

dato.

Entradas:

Por Pantalla:

Numero Carnet de Alumno

Por Sistema:

Cuando el sistema consulte los datos del alumno con el Número de Carnet

brindara estos datos al proceso.


- 36 -


Procesos:

Se solicitará el Numero de Carnet del alumno, se hará las búsqueda de la

información del estudiante, se cargaran en pantalla los datos que se ingresaron

en el momento de la matricula y se podrá editar dicha información.

Salida:

Una vez que se valide que los campos cumplen con el formato, se actualizaran

los datos registrados en la BD. Mostrará mensaje Actualizado con Éxito.

RF 4 Retirar Alumno

Introducción:

Esta función permitirá cambiar el estado de un estudiante de activo a inactivo en el caso

que abandone el centro CMML.

Entradas:

Por Pantalla:

Selección del Grupo

Selección de la opción Retirar correspondiente al alumno elegido.

Por Sistema:

El sistema consultará los datos del alumno seleccionado y los brindará al

proceso.

Procesos:

Se ingresara en el grupo en que está registrado el alumno, se elegirá la opción

Retirar del estudiante correspondiente y el estado del alumno será cambiado en

la BD a inactivo pero sin que se eliminen los datos por completo.

Salida:

Se mostrara la lista actualizada de los alumnos en el grupo.

RF 5 Ingresar Datos Docente

Introducción:

Se podrá registrar la información básica de un docente que iniciara a laborar en el

CMML.


- 37 -


Entradas:

Por Pantalla:

Nombres

Apellidos

Fecha de nacimiento (aa-mm-dd)

Cedula

Selección del sexo del docente

Selección de la religión

Teléfono

Celular

Dirección

Profesión

Otros estudios

Documentos Entregados

Procesos:

Se ingresarán los datos de docente, llenando los campos del formulario, el

sistema validará que los datos cumplan con el formato y los campos estén llenos,

se almacenarán los datos del docente en la BD.

Salida:

Una vez que se valide el formato de los campos, si el sistema detecta que se está

realizando un duplicado de un registro existente no almacenara ningún dato en

caso contrario ingresará el nuevo registro de docente en la BD, para ambas

situaciones mostrará un formulario vacío para ingresar nuevos registros.

RF 6 Actualizar Datos Docente

Introducción:

Este proceso permitirá la edición de los datos del maestro en caso de que se necesite

cambiar los datos actuales.

Entradas:

Por Pantalla:

Selección del docente a modificar.

Por Sistema:

La identificación del docente será brindada al proceso para consultar los datos en

la BD.

Procesos:

Se ingresara al listado de los docentes del centro, se seleccionará la opción

editar, se cambiarán los datos requeridos para que el registro este

actualizado, los datos serán almacenados.


- 38 -


Salida:

Se mostrará el expediente del docente con los datos actualizados.

RF 7 Retirar Docente

Introducción:

Esta función permitirá cambiar el estado de un docente de activo a inactivo en el caso de

no continuar laborando en el CMML.

Entradas:

Por Pantalla:

Lista de Docentes

Selección de la opción Retirar.

Por Sistema:

Se brindara el id del docente al proceso para la búsqueda de los datos

correspondientes.

Procesos:

Se ingresará al listado de los docentes, selección de la opción Retirar para el

docente correspondiente.

Salida:

Se mostrará la lista actualizada de los docentes activos en el colegio.

RF 8 Añadir Asignatura

Introducción:

Este proceso permite que se guarde el nombre y descripción de una materia que iniciará

a impartirse en el CMML.

Entradas:

Por Pantalla:

Nombre de la Asignatura

Categoría

Por Sistema:

Id de la Asignatura será brindado al proceso.


- 39 -


Procesos:

Se ingresará el nombre de la asignatura y la categoría en la que estaría incluida

esa materia, se creará un id para la asignatura que será utilizado internamente

por el sistema como referencia.

Salida:

Listado Actualizado de las asignaturas en el pensum.

RF 9 Retirar Asignatura

Introducción:

Se podrá cambiar el estado de una asignatura a estado inactivo cuando no se valla a

seguir impartiendo.

Entradas:

Por Pantalla:

Listado de la asignaturas.

Selección de la opción Retirar.

Por Sistema:


Procesos:

Se ingresará a las asignaturas para visualizar el listado de asignaturas inscritas,

se elegirá la opción Retirar correspondiente a la asignatura que no estará siendo

impartida.

Salida:

Listado actualizado de las asignaturas activas en el centro.

RF 10 Restablecer Asignatura

Introducción:

Será posible la activación de una asignatura que fue retirada por error o que decidió

incluirse una vez más en el pensum.


- 40 -


Entradas:

Por Pantalla:

Listado de la asignaturas.

Selección de la opción Activar.

Por Sistema:


Procesos:


se elegirá la opción Activar correspondiente a la asignatura que será impartida

una vez más en el CMML.

Salida:


RF11 Agregar Asignatura a Pensum

Introducción:

Será posible registra una asignatura al pensum académico

Entradas:

Por Pantalla:

Lema

Por Sistema:

El año lectivo correspondiente

Procesos:


se elegirá la opción Activar correspondiente a la asignatura que será impartida

una vez más en el CMML.

Salida:



- 41 -


RF 11 Abrir Secciones

Introducción:

Se podrá separar un grupo completo de alumnos en secciones para poder distribuir la

cantidad de estudiantes en grupos más pequeños.

Entradas:

Por Pantalla:

Grado del Grupo

Numero de Secciones.

Por Sistema:

Ninguna

Procesos:

Se elegirá el grupo que se va a separar en secciones, selección del número de

secciones en que será dividido el grupo, se registran las secciones para el grupo

y el total de estudiantes matriculados en el mismo será repartido

proporcionalmente en cada uno.

Salida:

Mostrará listado de grupos con el número de secciones actualizado.

RF 12 Cerrar Secciones

Introducción:

Esta función permitirá corregir cualquier error cometido en la división del grupo ya que

se unirán las secciones en un solo grupo o se distribuirán los alumnos en un número de

secciones menor.

Entradas:

Por Pantalla:

Listado de grupos con sus respectivas secciones.

Por Sistema:

Ninguna


- 42 -


Procesos:

Se visualizará el listado de grupos con sus secciones, se elegirá la opción Retirar

en la sección que se va a eliminar y el sistema unirá todos los alumnos en un

solo grupo para luego dividir o no el grupo en las secciones deseadas.

Salida:

Listado Actualizado de los grupos con sus secciones.

RF 13 Asignar Materia

Introducción:

Esta función permitirá delegar una asignatura a un maestro específico el cual será el

encargado de impartirla.

Entradas:

Por Pantalla

Grupo y Sección

Selección del Nombre del Docente

Selección del Nombre de la Asignatura

Por Sistema:

Se brindara el id del docente y el id de la asignatura al proceso para establecer la

relación.

Procesos:

Se seleccionará el grupo para el que estamos designando las asignaturas, se

elegirá el maestro y luego la asignatura que le será encargada, si se designa un

maestro con una materia de categoría Conducta será convertido automáticamente

en el profesor guía de ese grupo.

Salida:

Se mostrará el listado de las asignaturas con el docente elegido para impartirla.

RF 14 Desasignar Materia

Introducción:

Esta función se utilizará para retirar la asignación de una materia al docente

elegido, con el propósito de utilizar un docente diferente.


- 43 -


Entradas:

Por Pantalla:

Grupo

Por Sistema:

La relación entre el id del docente y el id de la asignatura es brindada al proceso.

Procesos:

Se elige el grupo, se podrán ver las asignaturas con el profesor que la imparte en

ese grupo, se elegirá la opción Borrar, se eliminará la relación entre el docente y

esa asignatura.

Salida:

Listado actualizado de las Materias Asignadas.

RF 15 Publicar Noticia

Introducción:

Se podrá ingresar noticias e información para mantener a los estudiantes atentos a las

actividades académicas.

Entradas:

Por Pantalla:

Título

Descripción de la noticia

Fecha y Hora de Publicación

Fecha y Hora de Caducidad

Por Sistema:

Ninguna

Procesos:

Se registrará un titulo para la noticia, se ingresará el texto que será publicado,

además de brindar la fecha en que fue publicado y la fecha de validez.

Salida:

Se muestra el formulario vacío para el ingreso de otra noticia.


- 44 -


RF 16 Asignar Acta Calificación

Introducción:

En esta función podremos guardar los datos del Acta en que están registradas las notas

de los parciales.

Entradas:

Por Pantalla:

Índice de acta (Libro-Acta-Folio)

Por Sistema:

Ninguna

Procesos:

Se ingresara el Número de Libro, de Acta y de Folio correspondiente y se

almacenará el dato.

Salida:

Se mostrará la lista actualizada de los grupos con su respectivo índice de acta.

RF 17 Asignar Acta Reparación

Introducción:

En esta función podremos guardar los datos del Acta en que están registradas las notas

de reparación.

Entradas:

Por Pantalla:

Índice de acta (Libro-Acta-Folio)

Por Sistema:

Ninguna

Procesos:

Se ingresara el Número de Libro, de Acta y de Folio correspondiente y se

almacenará el dato.

Salida:

Se mostrará la lista actualizada de los grupos con su respectivo índice de acta.


- 45 -


RF 18 Subir Fotos

Introducción:

Se podrá ingresar fotos de las actividades académicas y extracurriculares del CMML.

Entradas:

Por Pantalla:

Titulo

Comentario de la Foto

Ruta de ubicación del archivo

Por Sistema:

Se envía la ruta de la ubicación del archivo al sistema

Procesos:

El sistema buscará la ruta que se proporcione y añadirá el archivo especificado,

además se ingresara algún comentario con la fotografía a manera de descripción

de la actividad que se estaba realizando.

Salida:

Se mostrara mensaje Se añadió foto con éxito.

RF 19 Eliminar Fotos

Introducción:

Esta función podrá utilizarse para eliminar o borrar la foto que se había añadido con el

propósito de tener una galería actualizada o corregir si se había añadido por error.

Entradas:

Por Pantalla:

Lista de las fotos actuales.

Selección de la opción Eliminar.

Por Sistema:

Se envía la ruta de ubicación del archivo al sistema.

Procesos:

El usuario seleccionará la foto que no desea permanezca en la galería y al

seleccionar la opción Eliminar se borrara de la galería.

Salida:

Se mostrará la galería actualizada.


- 46 -


RF 20 Editar Pagina Estática

Introducción:

Con esta función se podrá editar la información de las páginas estáticas que contienen la

información básica del CMML.

Entradas:

Por Pantalla:

Se introducirá el texto.

Por Sistema:

Ninguna

Procesos:

Se podrá actualizar la información contenida en la reseña histórica o en los

reglamentos por ejemplo, se introducirá todo el texto actualizado y se guardará

para ser presentado.

Salida:

Se mostrará mensaje de Realizado con Éxito.

RF 21 Ingresar Nota Parcial

Introducción:

Con esta función el docente será capaz de ingresar una nota parcial para la asignatura

que este impartiendo.

Entradas:

Por Pantalla:

Contraseña del Docente

Nota Parcial

Procesos:

El docente tendrá que ingresar su usuario y contraseña, se muestra la lista de

materias impartidas por el docente en cual al seleccionar para ingresar las notas

correspondientes se muestra la lista de los alumnos que llevan dicha materia,

luego de ingresar las notas se mostrarán las notas de los parciales anteriores

Salida:

Notas de los alumnos y su nota final actualizadas del alumno.


- 47 -


RF 22 Ingresar Nota Reparación

Introducción:

Con esta función el docente será capaz de ingresar una nota de reparación para la

asignatura que imparte.

Entradas:

Por Pantalla:

Contraseña del Docente

Nota de Reparación

Procesos:

El docente tendrá que ingresar su usuario y contraseña, se muestra la lista de

materias impartidas por el docente la cual se seleccionara para ingresar las notas

correspondientes, se muestra la lista de los alumnos que reparan dicha materia y

que alcanzaron el derecho, luego de ingresar la nota de reparación.

Salida:

Se mostraran las notas de reparación de cada alumno.

RF 23 Modificar Nota

Introducción:

Con esta función la dirección será capaz de modificar una nota parcial para una

asignatura cuando sea necesario corregirla.

Entradas:

Por Pantalla:

Carnet del Alumno

Nota Parcial

Procesos:

El proceso pedirá el número de carnet del alumno, se obtendrá como resultados

las asignaturas con las notas correspondientes, y en ese momento se hará una

sustitución de la nota actual por la nueva y se guardarán los datos.

Salida:

Se mostraran las asignaturas con sus correspondientes notas.


- 48 -


RF 24 Modificar Nota Reparación

Introducción:

Con esta función la dirección será capaz de modificar una nota de reparación para una

asignatura cuando sea necesario corregirla.

Entradas:

Por Pantalla:

Carnet del Alumno

Nota Reparación

Procesos:

El proceso pedirá el número de carnet del alumno, se obtendrá como resultados

las asignaturas con las notas correspondientes, en ese momento añadirá la nota

de reparación y se guardarán los datos.

Salida:

Se mostraran las asignaturas con sus correspondientes notas reparación de la

materia.

RF 25 Mostrar Estadísticas

Introducción:

Este proceso permite conocer el rendimiento académico obtenido por año lectivo, en

determinada asignatura, por el grupo de Docentes, a nivel de Primaria, Secundaria y de

todo el colegio centro.

Entradas:

Por Pantalla:

Selección de la Opción Estadísticas.

Por sistema:

Año Académico

Asignatura

Grupo de Docentes

Primaria

Secundaria

Colegio

Procesos:

Se muestran cada una de las opciones mencionadas, para el caso de rendimiento

docente, se genera el rendimiento académico obtenido por los estudiantes de

cada docente de primaria, secundaria o todo el colegio.


- 49 -


Salida:

Se muestra los resultados según la opción proporcionada en la entrada.

RF 26 Cambiar Contraseña de Usuario

Introducción:

El administrador de SAGAT será capaz de administrar las cuentas de usuario,

específicamente podrá cambiar la contraseña de cada usuario del sistema.

Entradas:

Por Pantalla:

Nombre del Usuario

Contraseña Actual

Nueva Contraseña

Por Sistema:

Una vez validado el Nombre de Usuario y Contraseña, brindara los datos al

proceso.

Procesos:

Se buscara los datos del usuario por medio del nombre del mismo, se validara

que el campo Contraseña Actual coincida de hecho con la contraseña del

usuario, luego se actualizara el registro de la contraseña en la BD.

Salida:

Se mostrara mensaje de Cambio realizado con éxito.

RF 27 Respaldar BD

Introducción:

Esta operación es exclusiva del Administrador del sistema y permite realizar una copia

de seguridad de los datos de toda la base de datos.

Entradas:

Por Pantalla:

Selección de la opción Copia de Seguridad.

Por Sistema:

El sistema enviara el nombre de la BD y de las tablas que la componen al

proceso.

Procesos:


- 50 -


Se selecciona la opción Copia de Seguridad para indicar que se necesita realizar

respaldo de los datos almacenados actualmente en la BD.

Salida:

Se generará un archivo que puede ser guardado en cualquier dispositivo de

almacenamiento.

RF 28 Restaurar BD

Introducción:

Esta función permite a partir de una copia de seguridad, restaurar los datos de los

respaldos

Entradas:

Por Pantalla:

Selección de la Opción Restaurar Copia de Seguridad.

Por Sistema:

Ruta de ubicación del archivo

Procesos:

Seleccionar la Opción Restablecer Copia de Seguridad, se no permitirá elegir la

ruta de ubicación del archivo de respaldo que va a ser cargado por el sistema y

contiene los datos previamente respaldados.

Salida:

Se mostrara mensaje Copia de Seguridad Restaurada.

RF 29 Visualizar Notas

Introducción:

Los estudiantes serán capaces de consultar en línea sus notas parciales, notas de

reparación y el promedio de estas notas.

Entradas:

Por Pantalla:

Numero de Carnet del Alumno

Procesos:

El alumno ingresara su número de carnet y el sistema consultara en la BD por

los datos y las notas que se han registrado para este estudiante en cada

asignatura.

Salida:


- 51 -


Tabla de notas parciales, nota fina y/o de reparación por cada asignatura.

RF 31 Eliminar Noticia

Introducción:

Esta función permitirá al administrador del sistema la eliminación de una noticia, ya sea

por un error en la publicación o por su caducidad en fecha de valides.

Entradas:

Por Pantalla:

Lista de las noticias publicadas.

Por Sistema:

Envía el id de noticia la cual será eliminada

Procesos:

Se podrá eliminar una noticia dando en la opción del eliminar que proporciona el

sistema.

Salida:

Se muestra la lista de las noticias actualmente publicadas.

RF 32 Restablecer Docente

Introducción:

Esta función permitirá al administrador del sistema modificar el estado de un docente en

el sistema, específicamente regresar al docente a su estado activo en el centro, ya sea

porque se retiro por error o porque ha vuelto a ejercer labores en el centro.

Entradas:

Por Pantalla:

Lista de los docentes inactivos con la opción restablecer.

Por Sistema:

Envía el id del docente que será reactivado.

Procesos:

Se podrá reactivar en sus labores un docente seleccionado la opción restablecer

que proporciona el sistema.

Salida:

Se muestra la lista de los docentes inactivos.


- 52 -


RF 33 Restablecer Alumno

Introducción:

Esta función permitirá al administrador del sistema pasar al estado activo a un alumno

que haya sido retirado del centro por error.

Entradas:

Por Pantalla:

Introducir el número de carnet del alumno a reactivar.

Por Sistema:

Envía el id del alumno a reactivar.

Procesos:

Se podrá reactivar a un alumno dando en la opción restablecer que proporciona

el sistema.

Salida:

Se muestran el nombre, apellido, fecha nacimiento, grado y estado puesto a

activo del alumno.

4.2.3. REQUISITOS NO FUNCIONALES

4.2.3.1. REQUISITOS DE RENDIMIENTO

Se espera que el sistema soporte un mínimo de 10 usuarios conectados desde la red

local y un mínimo de 15 usuarios conectados desde internet. Además se estima que el

sistema sea accedido por al menos 3 usuarios diariamente y que se agreguen nuevos

registros todos los días.

Se tiene planificado que con los 120 Gb de almacenamiento mínimo se puedan guardar

un mínimo de X registros.

4.2.3.2. RESTRICCIONES DE DISEÑO

El software se verá limitado por las limitaciones que tenga la plataforma en la cual se

ejecute, siempre y cuando se cumplan unos requisitos mínimos.


- 53 -


4.2.3.3. REQUERIMIENTOS HARDWARE Y SOFTWARE PARA EL SERVIDOR

Requisitos software

Disponer de un sistema operativo

Disponer de un servidor web.

Tener instalado un motor de base de datos

Tener instalado un navegador de Internet.

Requisitos hardware

Un ordenador con procesador dual-core a 2.0 Ghz o superiores.

2Gb de RAM como mínimo, se recomienda 4Gb.

Disponer del 80% de espacio libre en disco

4.2.3.4. REQUERIMIENTOS HARDWARE Y SOFTWARE PARA EL CLIENTE

Requisitos software

Tener instalado Macromedia Flash, última versión.

Tener instalado un navegador de Internet.

Requisitos hardware

Un ordenador con procesador de 1.2Ghz o superior.

1Gb de RAM como mínimo.

4.2.3.5. SEGURIDAD

El acceso a la información está restringido a ciertos usuarios del sistema, cada usuario

del sistema tiene permisos específicos para realizar operaciones sobre el mismo.

El acceso de la aplicación a la base de datos se hace por medio de un usuario y

contraseña. Además el envío de los nombres de usuarios y contraseñas se hace bajo

algoritmos de encriptación.

4.2.3.6. MANTENIBILIDAD

El administrador del sistema debe realizar copias de seguridad, y hacer el respaldo de

las mismas. Se recomienda realizar las copias mensualmente

4.2.3.7. PORTABILIDAD

El uso del lenguaje PHP proporciona al sistema la característica de ser accesible desde

cualquier plataforma de sistema operativo y con cualquier explorador web.


- 54 -

DISEÑO DEL SISTEMA

DISEÑO DEL SISTEMAS

5.1. DIAGRAMA DE CASOS DE USO

ALUMNO

SECRETARIA

DOCENTE

ADMINISTRADOR

DIRECTORA

Iniciar Sesion

Ingresar Nota

Ver Notas

Subir Imagenes

Editar Pagina Estatica

Eliminar Imagenes

Eliminar Noticia

Respaldar BD

Restaurar BD

Cambiar Contraseña

Matricular AlumnoActualizar Alumno

Retirar Alumno

Rematricular Alumno

Abrir Pensum

Ingresar Docente

Editar Datos Docente

Retirar Docente

Registrar Asignatura

Retirar Asignatura

Ingresar Noticia

Ver Estadisticas

Editar Nota

Editar Nota Reparacion

Ingresar Nota Reparacion

Asignar Acta Calificacion

Asignar Acta Reparacion

Asignar Materia

Desasignar MateriaAbrir Secciones

Cerrar Secciones

Reestablecer Asignatura

Figura 5.1. 1: Diagrama de Casos de Uso


- 55 -

DISEÑO DEL SISTEMA

5.2. DIAGRAMAS DE SECUENCIA

/ : SECRETARIA

/ : Pagina /BD/ : Matricula

1 : Inicia el proceso de matricula()

2 : Muestra formulario()

3 : Llena el formulario()

4 : Matricular()

5 : consulta por alumno existente()

6 : Valida consulta()

7 : Confirma consulta()

8 : Almacena los datos()

9 : Confirma registro guardado()

10 : Confirma exito en el registro del alumno()

Figura 5.2.1: D. Secuencia - Matricular Alumno


- 56 -

DISEÑO DEL SISTEMA

Rematricular alumno

Figura 5.2.2: D. de Secuencia - Rematricular Alumno

Figura 5.2.3: D. de Secuencia - Retirar Alumno


- 57 -

DISEÑO DEL SISTEMA

Figura 5.2.4: D. de Secuencia - Registrar Docente

Figura 5.2.5: D. de Secuencia - Retirar Docente


- 58 -

DISEÑO DEL SISTEMA

Figura 5.2.6: D. de Secuencia - Ingresar Asignatura

Figura 5.2.7: D. de Secuencia - Retirar Asignatura


- 59 -

DISEÑO DEL SISTEMA

Figura 5.2.8: D. de Secuencia - Asignar Materia

Figura 5.2.9: D. de Secuencia - Desasignar Materia


- 60 -

DISEÑO DEL SISTEMA

Figura 5.2.10: D. de Secuencia - Ingresar Nota Parcial

Figura 5.2.11: D. de Secuencia - Ingresar Nota Reparacion


- 61 -

DISEÑO DEL SISTEMA

Figura 5.2.12: D. Secuencia - Modificar Nota Parcial


- 62 -

DISEÑO DEL SISTEMA

Figura 5.2.13: D. de Secuencia - Modificar Nota Reparacion


- 63 -

DISEÑO DEL SISTEMA

Figura 5.2.14: D. de Secuencia - Asignar Acta Calificaciones

Figura 5.2.15: D. de Secuencia - Asignar Acta Reparaciones


- 64 -

DISEÑO DEL SISTEMA

Figura 5.2.16: D. de Secuncia - Abrir Secciones

Figura 5.2.17: D. de Secuencia - Cerrar Secciones


- 65 -

DISEÑO DEL SISTEMA

Figura 5.2.18: D. de Secuencia - Generar Certificado

Figura 5.2.19: D. de Secuencia - Ingresar Noticia


- 66 -

DISEÑO DEL SISTEMA

Figura 5.2.20: D. de Secuencia - Subir Imagen

Figura 5.2.21: D. de Secuencia - Eliminar Imagen

/BD/ : Pagina / : Album

/ : ADMINISTRADOR

1 : Sube foto nueva()

2 : crear album()

3 : obtenerURLImagen()

4 : guardarAlbum()

5 : Almacena en BD()

6 : Confirma imagen guardada()

7 : Confirma album creado()

/ : Album / : BD/ : Pagina

/ : ADMINISTRADOR

1 : selecciona imagen a eliminar del album()

2 : eliminarImagen()

3 : elimina registro en Bd()

4 : Actualiza album()

5 : Confirma imagen eliminada()

6 : Confirma imagen borrada con exito()


- 67 -

DISEÑO DEL SISTEMA

5.3. DIAGRAMA DE CLASES

Para el diseño del diagrama de clases utilizamos el Modelo Vista Controlador

(MVC) es un patrón o modelo de abstracción de desarrollo de software que separa los

datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres

componentes distintos.

Es por lo que la aplicación está dividida en 3 capas, la primera es la capa de

Persistencia que es la encargada de la comunicación directa con la base de datos, la

segunda es la capa de Proceso en la que se encuentran las clases que definen el

funcionamiento de la aplicación y por último la capa de Presentación en la que se

encuentran todos los scripts que dan forma a la pagina.

5.3.1. CAPA PERSISTENCIA (Capa de Negocios)

En esta capa se encuentra establecida la conexión con la base de datos, es la que permitirá

el almacenamiento, modificación y visualización de los datos del sistema. Existe una clase

central que es BasedeDatos que es construida a partir de la clase

ManejadorBaseDeDatosInterface en la que se declaran los métodos pero que se relaciona

dependientemente de las clases SqlDelete, SqlUpdate, SqlInsert y SqlSelect.

Figura 5.3. 1: D. de Clases - Capa de Persistencia


- 68 -

DISEÑO DEL SISTEMA

5.3.2. CAPA PROCESO (Capa de Aplicación)

En esta capa se encuentran todas las clases que manejan el funcionamiento la

aplicación, en cada clase participan métodos que contienen clases de la Capa de

Persistencia.

Album

-idalbum: Integer+titulo: String-portada: String-fechapublicacion: Date-descripcion: String

+constructor()+guardarAlbum()+obtenerURLImagen(imagen: String): String+asignarPortada(idimagen: Integer, idalbum: Integer): Array+obtenerAlbum(): Array+eliminarAlbum(id: Integer): void+subirImagen(tema: String, imagen: String, descripcion: String, idalbum: Integer)+obtenerImagenesDeAlbum(id: Integer): Array+eliminarImagen(id: Integer): void+ultimoAlbum(): Array

PaginaEstatica

-titulo: String-contenido: Text-imagen: String-autor: String

+construct(titulo: String, imagen: Array, contenido: String, autor: String)+guardarPagina(): void+obtenerPaginaPorTitulo(titulo: String): Array+obtenerPaginaPorId(idpagina: String): Array+obtenerPaginas(): Array+editarPagina(idpagina: String, imagen: Array, contenido: String): String

MensajeDeError

-mensajeError: String-ruta: String

+construct(mensajeError: String, ruta: string)+determinarTipoDeMensaje(): String+obtenerOrigenDelError(): String

MiExcepcion

+construct(menssage: String, code: Integer, previous: Exeption)+mensajePersonalizado(): String

Noticia

-titulo: string+noticia: text-fechaPublicacion: date+fechaValides: date

+Construct(titulo, noticia, fechpub, fechval)+guardarNoticia(): void+obtenerNoticias(): Array+listarNoticias(): Array+eliminarNoticias(idnoticia): Array

Reparacion

-idralumno: String-idrasignatira: String-anyo: Integer-nota: Integer

+construct(idalumno: String, idasignatura: String, anyo: Integer, nota: Integer)+guardarReparacion(): void+mostrarNotaReparacion(asignatura: String, nivel: Integer, seccion: Integer): Array+obtenerNotaAsignaturaReparada(idalumno: String, idasignatura: String, anyo: Integer): Array+obtenerNotaDeReparacion(id: String): Array+actualizarNotaReparacion(notaRepar: Integer, idalum: String, idasign: String): Array+asignarLibroActaFolio(laf: Integer, grado: Integer, seccion: Integer)

Certificado

-año: Integer-nivel: Integer

+construct(idalumno: String, anyo: Integer, nivel: Integer)+obtenerCertificado(idalumno: String, nivel: Integer): String+obtenerMultiCertificado(idalum: String, nivelSup: Integer, nivelInfe: Integer): Array-eliminarGradosRepetidos(historial: Array): Array

Calificacion

-idalumno: String-idasignatura: String-anyo: Date-nota: Integer-parcial: Char+ciclo: Integer

+construct(idalumno: String, anyo: Intger, nota: Integer, idasignatura: String, parcial: Char, ciclo: Char)+parcialActual(idalumno: String, anyo: Integer, idAsignatura: String, ciclo: Char): Char+guardarCalificacion(): void+mostrarCalificaciones(nivel: Intege, seccion: Char, asignatura: String): Array+obtenerAlumnosQueRepararan(nivel: Integer, seccion: Char, idAsignatura: String): Array+verificarDerechoparaReparar(idalumno: String): Boolean+obtenerCalificaciones(id: String): Array+obtenerCalificacionesPorDocenteGuia(idDocente: String): Array+asignarLibroActaFolio(laf: String, grado: Integer, seccion: Char): String+actualizarCalificaciones(I: Integer, II: Integer, III: Integer, IV: Integer, idalum: String, idasig: String, ciclo: Char): String+obtenerCalificacionNivel(idalumno: String, anyo: Integer): Array

Figura 5.3. 2: D. de Clases - Capa de Proceso


- 69 -

DISEÑO DEL SISTEMA

Progenitor

-nombre: String-apellido: String-cedula: String-trabaja: String-oficio: String-lugar: String-telefono: Integer+idrhijo: String

+construct(nom: String, ape: String, ced: String, trab: String, of: Stringi, lug: String, tel: Integer, ide: String)+guardarProgenitor(): void+obtenerProgenitores(idAlumno: String): Array

IdAlumno

-id: string-curso: integer-sexo: char

+construct(curso: integer, sexo: char)+obtenerId(): String-idDisponible(): Integer

IdAsignatura

-id: string-añoRegistro: integer

+obtenerId(): String-idDisponible(): Integer

IdMatricula

-id: string-curso: integer

+construct(curso: Integer)+obtenerId(): String-idDisponible(): IntegerID

+generarId(Id: Object)

Asignatura

-asignatura: String-area: String-estado: Boolean

+construct(asignatura: Sring, area: String)+guardarAsignatura(): void+listarAsignaturas(): Array+obtenerAsignaturas(): Array+retirarAsignatura(idAsignatura: String): String+restablecerAsignatura(idAsignatura: String): String

Matricula

-alumno: Alumno-papa: Progenitor-mama: Progenitor-año: Iinteger-nivel: Integer-seccion: Char-edad: Integer

+Construct(noAl, apAl, feNa, ced, sx, niv, rel, noP, apP, cdP, trbP, ofP, lugP, telP, noM, apM, cedM, trbM, ofM, lugM, telM, vve, tut, telT, paren, dirA, bau, com, bauza, ent, obs)+GuardarMatricula(void)+ObtenerAlumnosPorNivel(nivel, seccion, curso): Array+Rematricular(nivel, relig, viv, tut, pare, direc, bau, comu, bauti, obser, entre)+ObtenerAlumnosPorNivelyAsignatura(nivel, seccion, asignatura): Array+ObtenerHermanosDeAlumno(idAlumno): Array+ObtenerHistorialAcademico(idAlumno): Array+actualizaDatosAlumnos(nivel, seccion, curso, religion, vive, tutor, parentesco, direccion): Array

Alumno

-nombre: String-apellido: String-fechaNacimiento: Date-cedula: String-sexo: Char-religion: String-vive: String-tutor: String-telefono: Integer-parentesco: String-direccion: String-bautizado: Char-comunion: Char-bautizarlo: Char-entregados: Text-observaciones: Text-estado: Boolean

+Construct(nom, ape, fechNa, ced, sx, rel, viv, tut, tel, pare, dir, bau, com, baz, ent, obs, sta)+guardarAlumno(): void+obtenerExpedienteDeAlumno(idAlumno: String): Array+obtenerDatosDeAlumno(idAlumno: String): Array+validarAlumno(idAlumno: String, fechaNacimiento: Date): Boolean+retirarAlumno(idAlumno: String): String+restaurarAlumno(idAlumno: String): String+obtenerAlumno(idAlumno: String): String

Imparte

-idasignatura-iddocente-nivel: String-seccion: Char

+construct(idasignatura: String, iddocente: String, nivel: Integer, seccion: Char)+guardarImparte(): void+asignaturasDeGrado(nivel: Integer, seccion: Char): Array+impartidaPorDocente(idAsignatura): Array+borrarAsignaturaImpartida(idAsignatura: String, nivel: Integer, seccion: Char): String+borrarAsignaturaEnImparte(idAsignatura: String): String

Grupo

-nivel: Integer-seccion: Char-iddocente: String+as: Char

+construc(grado: Integer, seccion: Char, idDocent: String)+guardarGuia(): void+docenteGuia(nivel: Integer, seccion: Char)+yaEsGuia(iddocente: String)+eliminarGuia(nivel: Integer, seccion: Char): String+listarGrupos(curso): Array+alumnosMatriculados(nivel: Integer): Integer+agregarGrupo(nivel: Integer, cantidad: Integer): String+grupoYaDividido(nivel): String+docenteGuia(grado: Integer, seccion: Char): String+gradoYaDividido(nivel: Integer): Boolean+deshacerDivicionDeGrado(grado: Integer): String

Docente

-nombre: String-apellido: String-fechaNacimiento: Date-clave: String-sexo: Char-religion: String-telefono: Integer-celular: Integer-direccion: String-profesion: String-estudios: Text-entregados: Text-estado: Boolean

+construct(nombDo, apellDo, fechnac, ced, sex, relig, tele, cel, direc, prof, estud, entr)+guardarDocente(): void+obtenerExpedienteDocente(idDocente: String): Array+listarDocentes(): Array+actualizarDatoDocente(idDoce: String, tel: Integer, cel: Integer, dir: String, estu: Text, entr: Text): String+retirarDocente(idDocente: String): String+restableceDocente(iddocente: String): String+obtenerDocentes(): Array

Estadistica

+construct()+matriculaColegio(): Integer+matriculaGrado(grado: integer): Integer+rendimientoColegio(): Float+rendimientoGrado(grado: Integer): Float+rendimientoAsignatura(idAsignatura: String): Float+rendimientoAsignaturaGrado(grado: Integer, idAsignatura: String): Float+rendimientoPrimaria(): Float+rendimientoSecundaria(): Float-consultaRendimiento(parcial: Char, tipo: String): String-consultaRendimientoGrado(parcial: Char, grado: Integer): String-consultaRendimientoAsignatura(parcial: Char, idAsignatura: String, grado: Integer): String+mejorAlumnoColegio(): Array+mejorAlumnoPrimaria(): Array+mejorAlumnoSecundaria(): Array+mejorAlumnoGrado(): Array-consultaMejorAlumno(parcial: Char, tipo: String): String-consultaMejorAlumnoGrado(parcial: Char, grado: Integer): String

Pensum

-anyoacademico: Date-lema: String-estado: Char

+construct(anyoacademico: Date, lema: String, estado: Char)+guardarPensum(): String+listarPensum(): Array-ultimoPensum(): Array+agregarAsignaturaPensum(idpensum: String, idasignatura: String, nivel: Integer, ciclo: Integer)+eliminarAsignaturaPensum(idpensum: String, idasignatura: String, nivel: Integer)+listarAsignaturasDePensum(nivel: Integer): Array+activarPensum(idpensum: String): Array-obtenerAsignaturasDePensum(idpensum: String): Array+clonarPensum(idpensum: String)

Usuario

+usuario: String+clave: String+tipo: Char+fechacam: Date+expira: Int

+constuct(usuario: String, clave: String, tipo: Char)+guardarUsuario()+verificarUsuario(usuario: String, clave: String): Int+cambiarClaveUsuario(usuario: String, clavAnt: String, nueClav: String): Bool+verificarExpiracionDeClave(u: String, c: String): Int+grabarIntentos(usuario: String)+desbloquearUsuario(usuario: String): Bool+listarUsuario(): Array-restablecerIntentos(usuario: String): Bool

Figura 5.3. 3: D. de Clases - Capa de Proceso (II)


- 70 -

DISEÑO DEL SISTEMA

5.3.3. CAPA PAGINA (Capa de Usuario)

En la Capa de Usuario existe una única clase Pagina la que se encarga a través del

manejo de scripts de darle apariencia a la aplicación y dar formato a los datos que se

ingresarán como los que se mostrarán.

Pagina

+activePage+acceso: String+formulario+content: String+contentSecundario+title: String+keywords: String+buttons: Array+menu: Array+usuarios: Array+permisos: Array+indicePermisos: Int+menu_Activo: String

+construct()+set(name: String, value: String)+display()+displayFormulario()+crearFormulario()+displayTitle()+displayKeywords()+cargarEstilosCSS()+displayHeader()+displayAutenticar()+displayMenu(buttons: Array)+foreach(buttons: Array)+displayMenuLateral(menu: Array)+displayContent()+displayContentSecundario()+displayFooter()

Figura 5.3. 4: D. de Clases - Capa de Presentación


- 71 -

DISEÑO DEL SISTEMA

5.4. DIAGRAMA ENTIDAD RELACION

Figura 5.4. 1: D. de Clases - BBDD SAGAT

nivel

Matricula

idpadre

nombre apellidos

trabaja

oficio lugar

telefono

cedula

idalumno

apellido

cedula

religi

on

nombre

fecha

naci sexo vive tutor

telefono direccion

parente

sco

bautiz

ado est

ado

bautiz

arlo

entrega

dos

comu

nion

idmatricula

nivel

año

seccion

idralumno edad

registra Padre tiene Alumno

año

I

II

III

IV

NF

laf

calificacion

es

seccion

estudios direccion

celular

estado

profesion

sexo

fechaNac

apellido

nombre

iddocente

religion

telefono

nivel seccion

idreparacion laf

Pensum

idpesum

anyolectivo lema estado

nivel ciclo

Reparación

Asignatura

idasignatura

area asignatura

estado

tieneasigna

repara

imparte Docente

clave

entregados


- 72 -

DISEÑO DEL SISTEMA

Figura 5.4. 2: D. E/R - BBDD RECURSOS

Noticias

fechapubli

idnoticia titulo

noticia

imagen

usuario clave

expiracion

tipo

timeexp

idusuario

Usuarios

PaginasEstaticas

idpagina

titulo

contenido

descripcion

imagen

contiene

edita modifica

administra

Imagen

imagen

idimagen tema

desscripcion

Album

Imagenes

portada

idalbum titulo

descripcion

imagen


- 73 -

DISEÑO DEL SISTEMA

5.5. DISEÑO DE DATOS

TABLA ALUMNOS

Almacena la información de los alumnos inscritos en el centro.

NOMBRE DESCRIPCION TIPO

Idalumno Llave primaria para identificar al alumno. VARCHAR(14)

Nombre Nombre del Alumno. VARCHAR(20)

Apellido Apellidos del Alumno. VARCHAR(20)

Fechanaci Fecha de nacimiento del alumno. DATE

Cedula Número del documento de identidad del Alumno. VARCHAR(16)

Sexo Género del Alumno. CHAR(1)

Religión Religión que profesa el alumno. VARCHAR(10)

Vive Define con quien vive el alumno. VARCHAR(6)

Tutor Nombre del responsable del alumno en caso de que no viva con los padres.

VARCHAR(40)

Teléfono Teléfono del tutor. VARCHAR(10)

Parentesco Parentesco del tutor con el alumno. VARCHAR(40)

Dirección Dirección de residencia del alumno. TEXT

Bautizado Si es o no bautizado. VARCHAR(2)

Comunión Si ha dado o no la primera comunión. VARCHAR(2)

Bautizarlo Progenitor o tutor confirma si desea bautizar al alumno en el centro.

VARCHAR(2)

Entregados Documentación entregada al momento de la matricula.

TEXT

Observaciones

Cualquier información relevante a la salud del alumno.

TEXT

Estado Estado del alumno en el centro. Activo o no. BOOL

TABLA PROGENITOR

Almacena la información de los padres de familia.


Idpadre Llave primaria para identificar al progenitor. VARCHAR(16)

Nombre Nombre del Progenitor. VARCHAR(20)

Apellido Apellidos del Progenitor. VARCHAR(20)

Cedula Número del documento de identidad del Progenitor. VARCHAR(16)

Trabaja Confirmación si el Progenitor trabaja. Respuesta si o no.

VARCHAR(2)

Oficio Profesión del Progenitor. VARCHAR(20)

Lugar Lugar del trabajo del Progenitor VARCHAR(20)

Teléfono Teléfono del Progenitor VARCHAR(9)


- 74 -

DISEÑO DEL SISTEMA

TABLA MATRICULAS

Almacena los datos de la matricula del año lectivo.


Idmatricula Llame primaria, código identificador de la matricula.

VARCHAR(14)

Anyo Año Académico. YEAR

Nivel Nivel Académico del alumno. VARCHAR(3)

Sección Sección en la que se matriculará el alumno.

CHAR(2)

Edad Edad del Alumno. INT(2)

Idralumno Llave Foránea que relaciona con la tabla Alumnos

VARCHAR(14)

TABLA DOCENTE

Almacena los datos de los docentes del centro.


Iddocente Llave Primaria que identifica al docente. VARCHAR(16)

Nombre Nombre del docente. VARCHAR(20)

Apellido Apellidos del docente. VARCHAR(20)

Fechanaci Fecha de nacimiento del docente. DATE

Sexo Genero del docente. VARCHAR(1)

Clave Clave de usuario para ingresar al sist. VARCHAR(10)

Religión Religión que profesa el docente. VARCHAR(10)

Teléfono Número de teléfono del docente. VARCHAR(10)

Celular Numero de celular del docente. VARCHAR(10)

Dirección Dirección de residencia del docente. VARCHAR(80)

Profesión Profesión del docente. VARCHAR(24)

Estudios Títulos profesionales del docente. Cursos realizados por el docente.

TEXT

Entregados Documentación entregada por el docente. TEXT

Nivel Nivel asignado al docente para ser el guía.

VARCHAR(3)

Sección Sección asignada al docente para ser su guía.

CHAR(1)

Estado Estado del docente en el centro. Activo o Retirado.

BOOL


- 75 -

DISEÑO DEL SISTEMA

TABLA ASIGNATURA

Almacena los datos de las asignaturas impartidas en el centro.


Idasignatura Llave Primaria identifica la asignatura. VARCHAR(12)

Asignatura Nombre de la asignatura. VARCHAR(25)

Area Área académica en la que se enfoca la asignatura.

VARCHAR(33)

Estado Estado de la asignatura en el pensum. Activa o Retirada.

BOOL

TABLA PENSUM

Almacena la nota obtenida por el alumno en la asignatura reparada.


Idpensum Llave Primaria que identifica un registro en Pensum.

INT

AñoLectivo Año lectivo actual DATE

Lema Lema propuesto al inicio del año lectivo. VARCHAR(33)

Estado Pensum activo o no activo. BOOL

TABLA CALIFICACIONES

Almacena las notas parciales y nota final que obtiene un alumno por cada asignatura.


Idralumno Llave foránea que relaciona con tabla Alumnos

VARCHAR(14)

Idrasignatura Llave foránea que relaciona con tabla Asignatura.

VARCHAR(14)

Año Año académico que cursa el alumno. YEAR

I Nota del primer parcial. INT(3)

II Nota del segundo parcial. INT(3)

III Nota del tercer parcial. INT(3)

IV Nota del cuarto parcial. INT(3)

NF Nota final del año. Promedio de los cuatro parciales.

INT(3)

LAF Numero de Libro, Acta y Folio en que está inscrita la nota final del año lectivo.

VARCHAR(14)


- 76 -

DISEÑO DEL SISTEMA

TABLA TIENEASIGNA

Almacena la relación entre el pensum y las asignaturas dentro del mismo.


Idrasignatura Llave Foranea que identifica un registro en Asignatura.

INT

Idrpensum Llave Foranea que identifica un registro en Pensum.

INT

Nivel Nivel académico del alumno. VARCHAR(3)

Ciclo Ciclo o periodo dentro del año lectivo. INT

TABLA REPARACIONES

Almacena la nota obtenida por el alumno en la asignatura reparada.


Idreparacion Llave Primaria que identifica a la nota de reparación.

INT

Idralumcal Llave foránea que relaciona con la tabla Calificaciones.

VARCHAR(14)

Idasignacal Llave foránea que relaciona con la tabla Calificaciones.

VARCHAR(14)

LAF Numero de Libro, Acta y Folio en la que esta inscrita la nota de reparación.

VARCHAR(14)

TABLA PAGINAESTATICA

Almacena información que es presentada por el sistema.


Idpagina Llave Primaria, identifica la pagina. INT

Titulo Nombre de la página. VARCHAR(25)

Contenido Información que se mostrará en la página. TEXT

Imagen Ruta de ubicación de la imagen publicada en la página.

VARCHAR(100)

Autor Nombre del autor o redactor de la información presentada en la página.

VARCHAR(25)


- 77 -

DISEÑO DEL SISTEMA

TABLA USUARIOS

Almacena los datos de los usuarios que va


Idusuario Llave Foránea que identifica al usuario. INT

Usuario Nombre del usuario. VARCHAR(15)

Clave Clave de la cuenta de usuario. VARCHAR(13)

Tipo Carácter que identifica el usuario que inicia su sesión.

CHAR

Fechacam Fecha de la última modificación del usuario.

DATE

Expiracion Cantidad de días de validez de la clave de usuario.

CHAR

TABLA ALBUM

Almacena los datos del album que organiza las imágenes dentro del sistema.


Idalbum Llave Primaria, identifica la imagen. INT

Titulo Titulo que se le asigna a la imagen. VARCHAR(25)

Portada Ruta de ubicación de la imagen. VARCHAR(100)

Fechapublicacion Fecha en que el álbum fue creado DATE

Descripción Breve descripción de lo que representa la imagen.

TEXT


- 78 -

DISEÑO DEL SISTEMA

TABLA NOTICIAS

Almacena la información publicada a manera de noticias.


Idnoticia Llave Primaria, identifica la noticia. INT

Titulo Nombre o encabezado de la publicación. VARCHAR(50)

Noticia Descripción o detalle de la noticia que se presenta.

TEXT

Fechapublicacion Fecha en que se publicó la noticia. DATE

Fechavalidez Fecha en que la noticia no tendría validez o no sería relevante.

DATE

TABLA IMAGENES

Almacena los datos de las imágenes presentadas en el sistema.


Idimagen Llave Primaria, identifica la imagen. INT

Tema Titulo que se le asigna a la imagen. VARCHAR(25)

Imagen Ruta de ubicación de la imagen. VARCHAR(100)

Descripción Breve descripción de lo que representa la imagen.

TEXT

Idralbum Llave foránea que hace referencia al identificador de la tabla Album.

INT


- 79 -

CODIFICACIÓN DEL SISTEMA

5.7. MODELO RELACIONAL

Figura 5.7. 2: BD RECURSOS

Figura 5.7. 1: BD SAGAT


- 80 -



6.1. PHP

Es un lenguaje de programación interpretado, diseñado originalmente para la

creación de páginas web dinámicas. Es usado principalmente en interpretación del lado

del servidor (server-side scripting) pero actualmente puede ser utilizado desde una

interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo

aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.

PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor

(inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por

Rasmus Lerdorf en 1994. Publicado bajo la PHP License, la Free Software Foundation

considera esta licencia como software libre.

6.1.1. HISTORIA

Fue originalmente diseñado en Perl, con base en la escritura de un grupo de CGI

binarios escritos en el lenguaje C por el programador danés-canadiense Rasmus Lerdorf

en el año 1994 para mostrar su currículum vítae y guardar ciertos datos, como la

cantidad de tráfico que su página web recibía. El 8 de junio de 1995 fue publicado

"Personal Home Page Tools" después de que Lerdorf lo combinara con su propio Form

Interpreter para crear PHP/FI.

* PHP 3: Dos programadores israelíes del Technion, Zeev Suraski y Andi Gutmans,

reescribieron el analizador sintáctico (parser en inglés) en el año 1997 y crearon la base

del PHP3, cambiando el nombre del lenguaje a la forma actual. Inmediatamente

comenzaron experimentaciones públicas de PHP3 y fue publicado oficialmente en junio

del 1998. Para 1999, Suraski y Gutmans reescribieron el código de PHP, produciendo lo

que hoy se conoce como motor Zend. También fundaron Zend Technologies en Ramat

Gan, Israel.

* PHP 4: En mayo de 2000 PHP 4 fue lanzado bajo el poder del motor Zend Engine

1.0. El día 13 de julio de 2007 se anunció la suspensión del soporte y desarrollo de la

versión 4 de PHP.

* PHP 5: El 13 de julio de 2004, fue lanzado PHP 5, utilizando el motor Zend Engine

2.0 (o Zend Engine 2). La versión más reciente de PHP es la 5.3.3 (22 de julio de 2010),

que incluye todas las ventajas que provee el nuevo Zend Engine 2 como:

Mejor soporte para la Programación Orientada a Objetos, que en versiones

anteriores era extremadamente rudimentario.

Mejoras de rendimiento.

Mejor soporte para MySQL con extensión completamente reescrita.

Mejor soporte a XML ( XPath, DOM, etc. ).

Soporte nativo para SQLite.

Soporte integrado para SOAP.

http://es.wikipedia.org/wiki/Acr%C3%B3nimo_recursivo

http://es.wikipedia.org/wiki/Perl

http://es.wikipedia.org/wiki/Common_Gateway_Interface

http://es.wikipedia.org/wiki/C

http://es.wikipedia.org/wiki/1997



http://es.wikipedia.org/wiki/Motor_Zend

http://es.wikipedia.org/wiki/13_de_julio


- 81 -


Iteradores de datos.

Manejo de excepciones.

Mejoras con la implementación con Oracle.

6.1.2. CARACTERISTICAS

o Es un lenguaje multiplataforma.

o Completamente orientado al desarrollo de aplicaciones web dinámicas con

acceso a información almacenada en una Base de Datos.

o El código fuente escrito en PHP es invisible al navegador y al cliente ya que

es el servidor el que se encarga de ejecutar el código y enviar su resultado

HTML al navegador. Esto hace que la programación en PHP sea segura y

confiable.

o Capacidad de conexión con la mayoría de los motores de base de datos que

se utilizan en la actualidad, destaca su conectividad con MySQL y

PostgreSQL. Capacidad de expandir su potencial utilizando la enorme

cantidad de módulos (llamados ext's o extensiones).

o Posee una amplia documentación en su página oficial, entre la cual se

destaca que todas las funciones del sistema están explicadas y ejemplificadas

en un único archivo de ayuda.

o Es libre, por lo que se presenta como una alternativa de fácil acceso para

todos.

o Permite aplicar técnicas de programación orientada a objetos.

o Biblioteca nativa de funciones sumamente amplia e incluida.

o No requiere definición de tipos de variables aunque sus variables se pueden

evaluar también por el tipo que estén manejando en tiempo de ejecución.

o Tiene manejo de excepciones (desde PHP5).

Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a la hora de

programar (muchos otros lenguajes tampoco lo hacen), aun estando dirigido a alguna en

particular, el programador puede aplicar en su trabajo cualquier técnica de

programación y/o desarrollo que le permita escribir código ordenado, estructurado y

manejable. Un ejemplo de esto son los desarrollos que en PHP se han hecho del patrón

de diseño Modelo Vista Controlador (o MVC), que permiten separar el tratamiento y

acceso a los datos, la lógica de control y la interfaz de usuario en tres componentes

independientes (ver más abajo Frameworks en PHP).

6.2. ESTANDAR ZEND

Los estándares nos permiten disminuir muchos costos que surgen a la hora de

desarrollar sistemas que van desde la incorporación de nuevos recursos hasta el

entendimiento de los sistemas "legacy" ("sistemas heredados") que existen en cualquier

organización, ayudan a asegurar que el código tenga una alta calidad, menos errores, y

pueda ser mantenido fácilmente. Si todos los desarrolladores programan como quieren,

o cualquiera inventa su "propio estándar" o toma el de "cualquier estándar que use otro

proyecto", indudablemente esto significará caos.

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o



http://es.wikipedia.org/wiki/Dato


- 82 -


Zend es la empresa que desarrolla en la actualidad lo que puede considerarse

el Framework Oficial de PHP y también es la responsable de desarrollar el propio

lenguaje PHP como se mencionó.

El motor Zend es un motor de procesamiento para la interpretación y cifrado del

código php, desde la versión 4. Desarrollado por Zend Technologies para brindar un

equipo de soporte y acelerar la carga de aplicaciones realizadas con php.

Entre las funciones más importantes que realiza este motor de procesamiento está la

posibilidad de cifrar el código fuente de las páginas desarrolladas en php para así luego

hacer posible la comercialización de este.

6.2.1. REGLAS DEL ESTANDAR

General

Para archivos que contengan únicamente código PHP, la etiqueta de cierre ("?>") no

está permitida. No es requerida por PHP.

Identación

La identación suele estar compuesta por 4 espacios. Las tabulaciones no están

permitidas.

Tamaño máximo de línea

La longitud recomendable para una línea de código es de 80 caracteres. Líneas más

largas pueden ser aceptables en algunas situaciones. El tamaño máximo de cualquier

línea de código PHP es de 120 caracteres.

Final de línea

El Final de Línea sigue la convención de archivos de texto Unix. Las líneas deben

acabar con un carácter linefeed (LF).

Nombres de Archivo

Para cualquier otro archivo, sólo caracteres alfanuméricos, barras bajas (_) y guiones (-)

están permitidos. Los espacios en blanco están estrictamente prohibidos. Cualquier

archivo que contenga código PHP debe terminar con la extensión " .php ", con la

excepción de los scripts de la vista.

6.2.2. FUNCIONES Y METODOS

Los nombres de funciones pueden contener únicamente caracteres alfanuméricos.

Los guiones bajos (_) no están permitidos. Los nombres de funciones deben empezar

siempre con una letra minúscula. Cuando un nombre de función consiste en más de una

palabra, la primera letra de cada nueva palabra debe estar en mayúsculas. Esto es

llamado comúnmente como formato "camelCase".

Variables

Los nombres de variables pueden contener caracteres alfanuméricos. Las barras

bajas (_) no están permitidas. Para las variables de instancia que son declaradas con el

http://es.wikipedia.org/wiki/Php


- 83 -


modificador "private" o "protected", el primer carácter de la variable debe ser una única

barra baja (_). Este es el único caso admisible de una barra baja en el nombre de una

variable. Las variables declaradas como "public" no pueden empezar nunca por barra

baja.

Demarcación de código PHP

El código PHP debe estar delimitado siempre por la forma completa de las etiquetas

PHP estándar:

<?php ?>

Las etiquetas cortas (short tags) no se permiten nunca.

Declaración de clases

Las Clases deben ser nombradas de acuerdo a laconvención de nombres de Zend

Framework. La llave "{" deberá escribirse siempre en la línea debajo del nombre de la

clase ("one true brace"). Cada clase debe contener un bloque de documentación acorde

con el estándar de PHPDocumentor. Todo el código contenido en una clase debe ser

separado con cuatro espacios. Únicamente una clase está permitida por archivo PHP

Declaración de Funciones y Métodos

Las Funciones deben ser nombradas de acuerdo a las convenciones de nombrado de

Zend Framework. Los métodos dentro de clases deben declarar siempre su visibilidad

usando un modificador private , protected , o public .

Como en las clases, la llave "{" debe ser escrita en la línea siguiente al nombre de la

función ("one true brace" form). No está permitido un espacio entre el nombre de la

función y el paróntesis de apertura para los argumentos.

Sentencias de Control

Las sentencias de control basadas en las construcciones if y elseif deben tener un solo

espacio en blanco antes del paréntesis de apertura del condicional y un solo espacio en

blanco después del paréntesis de cierre.

Dentro de las sentencias condicionales entre paréntesis, los operadores deben

separarse con espacios, por legibilidad. Se aconseja el uso de paréntesis internos para

mejorar la agrupación lógica en expresiones condicionales más largas.

La llave de apertura "{" se escribe en la misma línea que la sentencia condicional.

La llave de cierre "}" se escribe siempre en su propia línea. Cualquier contenido dentro

de las llaves debe separarse con cuatro espacios en blanco.

6.3. XAMPP

Es un servidor independiente de plataforma, software libre, que consiste

principalmente en la base de datos MySQL, el servidor web Apache y los intérpretes

para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para

cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl.


- 84 -


El programa está liberado bajo la licencia GNU y actúa como un servidor web libre,

fácil de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está

disponible para Microsoft Windows, GNU/Linux, Solaris y MacOS.

6.3.1. CARACTERISITICAS Y REQUISITOS

XAMPP solamente requiere descargar y ejecutar un archivo zip, tar o exe, con unas

pequeñas configuraciones en alguno de sus componentes que el servidor Web

necesitará. XAMPP se actualiza regularmente para incorporar las últimas versiones de

Apache/MySQL/PHP y Perl. También incluye otros módulos como OpenSSL y

phpMyAdmin.

6.3.2. APLICACIONES

Realmente el propósito de los diseñadores de XAMPP era proveer de una

herramienta de desarrollo, para permitir a los diseñadores de sitios webs y

programadores probar los proyectos sin ningún acceso a Internet. Pero en la práctica,

XAMPP también es utilizado actualmente como servidor de sitios Web, puesto que solo

se necesitan algunas modificaciones para que funcione como tal y es generalmente lo

suficientemente seguro para serlo.

6.4. CSS

El nombre hojas de estilo en cascada viene del inglés Cascading Style Sheets, del

que toma sus siglas. CSS es un lenguaje usado para definir la presentación de un

documento estructurado escrito en HTML o XML (y por extensión en XHTML). El

W3C (World Wide Web Consortium) es el encargado de formular la especificación de

las hojas de estilos que servirán de estándar para los agentes de usuarios o navegadores.

La idea por lo cual CSS fue desarrollado, es para separar la estructura de un

documento de su presentación. El código propio de los estilo puede ser agregado como

un independiente separado o incluirse en el documento HTML. Para el último caso se

pueden definir estilos generales en la cabecera del documento o en cada etiqueta

particular por mediodel atributo "<style>".

6.4.1. CSS 2.1

La primera revisión de CSS2, normalmente conocida como "CSS 2.1", permitió

corregir algunos errores que se hallaron en CSS2, eliminando funcionalidades poco

soportadas o inoperables en los navegadores y añadiendo nuevas especificaciones.

De acuerdo al sistema de estandarización técnica de las especificaciones, CSS2.1

tuvo el estatus de "candidato" (candidate recommendation) durante varios años, pero la

propuesta fue rechazada en junio de 2005; en junio de 2007 fue propuesta una nueva

versión candidata, y ésta actualizada en 2009, pero en diciembre de 2010 fue

nuevamente rechazada.


- 85 -


En abril de 2011, CSS 2.1 volvió a ser propuesta como candidata, y después de ser

revisada por el W3C Advisory Committee, fue finalmente publicada como

recomendación oficial el 7 de junio de 2011.

6.5. JAVA SCRIPT

Es un lenguaje de programación interpretado, dialecto del estándar ECMAScript.

Se define como orientado a objeto basado en prototipos, imperativo, débilmente tipado

y dinámico.

Es usado principalmente del lado del cliente (client-side), implementado como parte

de un navegador web permitiendo así mejorar la interfaz de usuario y las páginas

web dinámicas, aunque también existe una forma de JavaScript del lado del

servidor (Server-side JavaScript o SSJS).

También es usado en aplicaciones externas a la web, por ejemplo en

documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) lo que hace su

uso algo significativo.

JavaScript se diseñó con una sintaxis similar al lenguaje C, aunque adopta nombres

y convenciones del lenguaje de programación Java. Sin embargo Java y JavaScript no

están relacionados, sus semánticas y propósitos son diferentes.

Todos los navegadores modernos interpretan el código JavaScript integrado en las

páginas web. Para interactuar con una página web el lenguaje JavaScript es provisto de

una implementación del Document Object Model (DOM).

Anteriormente se venía utilizando en páginas web HTML para realizar operaciones

y específicamente para la aplicación cliente, sin acceso a funciones del servidor.

JavaScript se interpreta en el agente de usuario, al mismo tiempo que las sentencias van

descargándose junto con el código HTML.

6.6. XHTML

Siglas del inglés eXtensible HyperText Markup Language. XHTML es realmente

HTML expresado como XML válido. Se dice que es más estricto a nivel técnico,

permitiendo así ser más fácil al hacer cambios o buscar errores entre otros.

En la versión 1.0, XHTML es realmente una versión XML de HTML, por lo que

tiene, básicamente, las mismas funcionalidades, pero cumple las especificaciones, más

estrictas, de XML. Tiene como objetivo avanzar en el proyecto del World Wide Web

Consortium de lograr una web semántica, donde la información, y la forma de

presentarla estén claramente separadas.

6.6.1. VENTAJAS RESPECTO AL HTML

Las principales ventajas del XHTML sobre el HTML son:


- 86 -


Se pueden incorporar elementos de distintos espacios de

nombres XML (comoMathML y Scalable Vector Graphics).

Un navegador no necesita implementar heurísticas para detectar qué quiso poner

el autor, por lo que el parser puede ser mucho más sencillo.

Como es XML se pueden utilizar fácilmente herramientas creadas para

procesamiento de documentos XML genéricos (editores, XSLT, etc.).

6.7. SQL

El lenguaje de consulta estructurado o SQL (por sus siglas en inglésstructured query

language) es un lenguaje declarativo de acceso a bases de datos relacionales que permite

especificar diversos tipos de operaciones en éstas. Una de sus características es el

manejo del álgebra y el cálculo relacionallo que permiterealizarconsultas con el fin de

recuperar -de manera sencilla- información de interés de una base de datos, así como

también hacer cambios sobre ella. Es un lenguaje de cuarta generación (4GL).

6.7.1. ORIGENES Y EVOLUCION

Los orígenes del SQL están ligados a los de las bases de datos relacionales. En 1970

E. F. Codd propone el modelo relacional y asociado a éste un sublenguaje de acceso a

los datos basado en el cálculo de predicados.

Los laboratorios de IBM se basaron en estas ideas para definir el lenguaje SEQUEL

(Structured English QUEry Language) que después pasaría ser ampliamente

implementado por el sistema de gestión de bases de datos experimental System R,

desarrollado en 1977 también por IBM. Pero realmente fue Oracle quien lo introdujo

por primera vez en 1979 en un programa comercial.

El SEQUEL fue el predecesor de SQL, siendo éste una versión evolucionada del

primero. El SQL pasó a ser el lenguaje por excelencia de los diversos sistemas de

gestión de bases de datos relacionales surgidos en los años siguientes y es por fin

estandarizado en 1986 por el ANSI, dando lo que dio lugar a la primera versión estándar

de este lenguaje, el "SQL-86" o "SQL1". Un año después el estándar fue también

adoptado por la ISO.

Pero este primer estándar no cubrió todas las necesidades de los desarrolladores.

Así que en 1992 se lanzó un nuevo estándar ampliado y revisado del SQL llamado

"SQL-92" o "SQL2". Actualmente el SQL es el estándar de facto de la gran mayoría de

los SGBD comerciales.

6.7.2. CARACTERISITICAS GENERALES

El SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y

potencia de los sistemas relacionales permitiendo gran variedad de operaciones en éstos

últimos.

http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

http://es.wikipedia.org/wiki/Consulta

http://es.wikipedia.org/wiki/Informaci%C3%B3n

http://es.wikipedia.org/wiki/Lenguaje

http://es.wikipedia.org/wiki/Datos

http://es.wikipedia.org/wiki/Oracle



- 87 -


Es un lenguaje declarativo de "alto nivel" o "de no procedimiento", que gracias a su

fuerte base teórica y su orientación al manejo de conjuntos de registros, y no a registros

individuales, permite una alta productividad en codificación y la orientación a objetos.

De esta forma una sola sentencia puede equivaler a uno o más programas que se

utilizarían en un lenguaje de bajo nivel orientado a registros.

Optimización

Como ya se ha mencionado, y suele ser común en los lenguajes de acceso a bases

de datos de alto nivel, el SQL es un lenguaje declarativo. O sea, que especifica qué es

lo que se quiere y no cómo conseguirlo, por lo que una sentencia no establece

explícitamente un orden de ejecución.

El orden de ejecución interno de una sentencia puede afectar gravemente a la

eficiencia del SGBD, por lo que se hace necesario que éste lleve a cabo una

optimización antes de su ejecución.

Muchas veces, el uso de índices acelera una instrucción de consulta, pero ralentiza

la actualización de los datos. Dependiendo del uso de la aplicación, se priorizará el

acceso indexado o una rápida actualización de la información. La optimización difiere

sensiblemente en cada motor de base de datos y depende de muchos factores.

6.8. APACHE

El servidor HTTP Apache es un servidor web HTTP de código abierto, para

plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que

implementa el protocolo HTTP/1.1 y la noción de sitio virtual.

Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del

popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se

debe a que Behelendorf quería que tuviese la connotación de algo que es firme y

enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se

convertiría en gobierno de EEUU, y en esos momentos la preocupación de su grupo era

que llegasen las empresas y "civilizasen" el paisaje que habían creado los primeros

ingenieros de internet.

Además Apache consistía solamente en un conjunto de parches a aplicar al servidor

de NCSA. En inglés, a patchy server (un servidor "parcheado") suena igual que Apache

Server. El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de

la Apache Software Foundation.

6.8.1. CARACTERISITICAS

Apache presenta entre otras características altamente configurables, bases de datos

de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz

gráfica que ayude en su configuración.

La mayoría de las vulnerabilidades de la seguridad descubiertas y resueltas tan sólo

pueden ser aprovechadas por usuarios locales y no remotamente. Sin embargo, algunas

se pueden accionar remotamente en ciertas situaciones, o explotar por los usuarios

http://es.wikipedia.org/wiki/Registro_(base_de_datos)


- 88 -


locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP

como módulo de Apache.

Apache es usado principalmente para enviar páginas web estáticas y dinámicas en la

World Wide Web. Muchas aplicaciones web están diseñadas asumiendo como ambiente

de implantación a Apache, o que utilizarán características propias de este servidor web.

Apache es el componente de servidor web en la popular plataforma de

aplicaciones LAMP, junto a MySQL y los lenguajes de

programación PHP/Perl/Python (y ahora también Ruby).

Apache es usado para muchas otras tareas donde el contenido necesita ser puesto a

disposición en una forma segura y confiable. Un ejemplo es al momento de compartir

archivos desde una computadora personal hacia Internet. Un usuario que tiene Apache

instalado en su escritorio puede colocar arbitrariamente archivos en la raíz de

documentos de Apache, desde donde pueden ser compartidos.

Los programadores de aplicaciones web a veces utilizan una versión local de

Apache con el fin de pre visualizar y probar código mientras éste es desarrollado.


- 89 -

CONCLUSIONES

CONCLUSIONES

Con la elaboración de este sistema, se ha logrado facilitar los procesos de gestión

académica del centro, así como también el acceso a la información del mismo.

Ahora a través del sistema al personal del centro le tomará menos trabajo y tiempo

ingresar la información de los alumnos, los docentes y otros datos académicos.

Se logró cumplir con cada una de las funciones requeridas para el sistema, así como

diseñar una interfaz amigable y de fácil manejo para los usuarios comunes.

Y por último consideramos que el sistema fomentará el uso de más sistemas

automatizados, por las bondades de estos proveen, o incluso incentivará a la mejora del

mismo dado que la manera a como fue desarrollado permite una fácil actualización.


- 90 -

RECOMENDACIONES

RECOMENDACIONES

Capacitar al personal del centro en el uso del sistema.

Instruir a los usuarios del sistema sobre la importancia de no compartir o permitir

que su clave de acceso al sistema sea del conocimiento de ajenos.

Mantener una constante actualización de la información, como lo es el retiro de

alumnos, bajas de docentes o bajas de asignaturas, a manera de permitir que los

datos sean consistentes.

Realizar respaldos y restauración de la base de datos de manera periódica (se

recomienda hacerlo cada tres meses).

Que el administrador haga cambios periódicos de las claves de los usuarios, para

evitar posibles violaciones al sistema.

Eliminar información referente a noticias antiguas e imágenes que no se usen más,

para evitar datos innecesarios.


- 91 -

BIBLIOGRAFÍA

BIBLIOGRAFÍA

Internet:

http://es.wikipedia.org

Libros:

Creación De Un Portal Con Php Y Mysql. 3ª Edición.

Editorial Ra-Ma

PAVON PUERTAS, JACOBO

Tecnología Y Diseño De Bases De Datos.

Editorial Ra-Ma

PIATTINI VELTHUIS, MARIO G ; MARCOS MARTINEZ, ESPERANZA ;

CALERO MUÑOZ, CORAL ; VELA SÁNCHEZ, BELÉN

Manual Imprescindible de PHP5.

Editorial: © EDICIONES ANA YA MULTIMEDIA (GRUPO ANAYA, S.A.),

2004

Luis Miguel Cabezas Granado

Programación Orientada a Objetos para PHP5. Edición julio 2009

Bajo licencia de Creative Commons. (http://creativecommons.org/licenses/by-

nc/3.0/)

Enrique Place.

PHP y MySQL para Dummies. 2da Edición.

Janet Valade

Sistemas de Bases de Datos, Conceptos Fundamentales. 2da Edición.

Editado: Addison – Wesley Iberoamericana

Ramez Elmasri, Shamkant B.Navathe.

Fundamentos de Sistemas de Bases de Datos. 5ta Edición.

Editado: Pearson Addison Wesley

Ramez Elmasri, Shamkant B.Navathe.

Fundamentos de Bases de Datos. 5ta Edición.

Editado: McGRAW-HILLDNTERAMERICANA DE ESPANA, S. A. U

Abraham Silberschatz, Henry F. Korth, S. Sudarshan.

Ingeniería del Software un Enfoque Practico. 5ta Edición.

Editado: McGRAW-HILLDNTERAMERICANA DE ESPANA, S. A. U

Roger S. Pressman

http://es.wikipedia.org/

http://www.agapea.com/libros/CREACIoN-DE-UN-PORTAL-CON-PHP-Y-MYSQL-3-EDICIoN--isbn-8478977546-i.htm

http://www.agapea.com/libros/TECNOLOGiA-Y-DISEnO-DE-BASES-DE-DATOS--isbn-8478977333-i.htm

http://creativecommons.org/licenses/by-

http://creativecommons.org/licenses/by-


- 92 -

BIBLIOGRAFÍA

Manual de PHP. Publicado 08-07-2002

Bajo licencia: Copyright © 1997, 1998, 1999, 2000, 2001, 2002 por el Grupo de

documentación de PHP por Stig Sæther Bakken, Alexander Aulbach, Egon

Schmid, Jim Winstead, Lars Torben Wilson, Rasmus Lerdorf, Andrei Zmievski,

y Jouni Ahto.

Los secretos de PHP y MySQL. Numero 30

Bajo Licencia: Copyright © KnowWare E.U.R.L.

Johann – Christian Hanke

PHP 5. Numero 28

Bajo Licencia: Copyright © KnowWare E.U.R.L.

Johann – Christian Hanke

MySQL 5.0 Reference Manual. Documento generado el: 2008-05-03 (revisión:

502)

Bajo Licencia: Copyright 1997-2007 MySQL AB

Curso completo de HTML

Bajo Licencia: GNU. Copyright Jorge Ferrer, Rodrigo Garcia y Victor García.

Jorge Ferrer, Víctor García, Rodrigo García

Introducción a CSS. Versión mayo 2009

Bajo Licencia: Creative Commons (http://creativecommons.org/licenses/by-nc-

nd/3.0/deed.es)

Javier Eguíluz Pérez

Introducción a JavaScript. Versión marzo 2009

Bajo Licencia: Creative Commons (http://creativecommons.org/licenses/by-nc-

nd/3.0/deed.es)

Javier Eguíluz Pérez

Desarrollo Web con PHP y MySQL. 3ra Edición

Editorial: © EDICIONES ANA YA MULTIMEDIA (GRUPO ANAYA, S.A.),

2005

Luke Welling, Laura Thomson.

IEEE Std 610.12-1990. Software Engineering Standards Committee of the IEEE

Computer Society

IEEE Std 830-1998. Software Engineering Standards Committee of the IEEE

Computer Society


- 93 -

ANEXOS

ANEXOS

Página de inicio

Página de inicio de sesión


- 94 -

ANEXOS

Lista de asignaturas

Lista de docentes


- 95 -

ANEXOS

Lista de estudiantes

universidad nacional autÓnoma de...

Documents