UNIVERSIDAD SAN PEDRO
FACULTAD DE INGENIERÍA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA
INFORMÁTICA Y DE SISTEMAS
CURSO DE TITULACIÓN EN INGENIERÍA INFORMÁTICA Y DE
SISTEMAS
“ANÁLISIS, DISEÑO Y DESARROLLO DE UN SISTEMA WEB
UTILIZANDO LA TÉCNICA AJAX PARA LOS PROCESOS DE
PROCESAMIENTO Y DIFUSIÓN DE INFORMACIÓN DE LA REVISTA
ALMA LIBERTANA”
INFORME PARA OBTENER EL TÍTULO PROFESIONAL DE
INGENIERO EN INFORMÁTICA Y DE SISTEMAS
PRESENTADO POR:
Bach. VERDE TRUJILLO Luis Rómulo
Bach. TREJO RODRIGUEZ Isidro Américo
ASESOR:
Ing.
HUARÁS – PERÚ – 2011
DEDICATORIA
A nuestros queridos padres por su sacrificio,
dedicación y apoyo incondicional que nos
brindan en nuestras vidas, fuerza que me
impulsa a conseguir mis ideales y objetivos.
Los Autores
i
AGRADECIMIENTO
A los docentes de la Universidad San Pedro, quienes
supieron formarnos en el ámbito profesional, social
y humano.
Al Ing. por la asesoría y el apoyo académico
profesional que nos brindó en el desarrollo del
presente proyecto.
Los Autores
ii
PRESENTACIÓN
Señores Miembros del Jurado:
En cumplimiento con el Reglamento de Grado y Títulos de la Universidad San Pedro,
tenemos a bien presentar a ustedes, nuestro informe de tesina titulada “PROPUESTA
DE REESTRUCTURACIÓN DE LA RED LAN PARA MEJORAR EL SISTEMA
DE COMUNICACIÓN DE LA DIRES- ANCASH”.
El desarrollo del presente informe contribuye con mejorar la comunicación entre los
diversos edificios y dentro de cada uno ellos de la institución DIRES – ANCASH, como
resultado del análisis de su red actual. La investigación concluye que la aplicación del
cableado estructurado en las instalaciones de la DIRES – ANCASH ayudara a mejorar
el sistema de comunicación.
Como todo Proyecto es susceptible de errores y algunas deficiencias por la falta de
experiencia profesional, dejamos a su criterio la evaluación de este proyecto, a fin de
que las observaciones que se emitan, sean los que consideren conveniente.
Los Autores
iii
RESUMEN
Este proyecto comprende en proponer una reestructuración del cableado de la red LAN
en la institución DIRES – ANCASH. Se ha desarrollado cumpliendo los estándares
EIA/TIA, se analizó la situación actual de la institución y se planteó un esquema para
mejorar la comunicación entre los diversos edificios e interiores de los mismos.
El diseño del cableado de la red se ha proyectado para optimizar la comunicación ya
que esto permitirá que el servicio de internet, compartimiento de recursos,
compartimiento de la información en la institución, sean más rápidas y eficientes, para
ello se tomó datos que permitan la adecuada reestructuración de la red, entre ellos se ha
recolectado información sobre: vías adecuadas para la instalación de los cables, puntos
adecuados para la las terminales, distribución adecuadas de los IP’s, calidad de equipos,
etc.
El análisis de costos toma en cuenta la mano de obra, precios de equipos y accesorios
existentes en el mercado y de este modo generar una propuesta adecuada para el
proyecto.
El presente proyecto técnico de investigación concluye que la reestructuración del
cableado de la red LAN, mejorará la comunicación y manejo de la información, de la
DIRES - ANCASH satisfaciendo las expectativas de los usuarios.
iv
ABSTRACT
This project consists on proposing the wiring of LAN network in the institution DIRES-
ANCASH. We have been fulfilling the standards EIA/TIA.
We analyzed the current situation in the institution and it was formed a scheme to
improve the communication among the different interior buildings the wiring design of
network has been projected to improve the communication so that, Internet service, the
distribution of the resources and the information would be faster and effective , for that
we took data that allow the appropriate restructuring of network from that we have
gathered information about appropriate ways for wiring installation, appropriate
locations and distribution of IPS and the quality of the equipment, etc.
Cost analysis includes the workforce, prices of the equipment, accessories that are in the
market So that, we can generate an appropriate proposal for this project.
This research project concludes that the restructuring of network wiring LAN, will
improve the communication and the information management of DIRES-ANCASH
satisfying the users expectations.
v
INTRODUCCION
Como es de conocimiento que los sistemas de comunicaciones se encuentran
tecnológicamente en los niveles de madurez, complejidad y desplazamiento, los cuales
son el soporte de la tecnología del software y hardware y por ende su aplicación traerá
consigo los beneficios para esta Institución del sector salud.
Las redes en general, consisten en compartir recursos, y uno de sus objetivos es hacer
que todos sus aplicativos, datos y equipo estén disponibles para cualquier usuario de la
Red, sin importar la localización física del recurso y del usuario.
Además de proporcionar un acceso compartido, las redes LAN modernas también
proporcionan al usuario multitud de funciones avanzadas. Hay paquetes de software de
función para controlar la configuración de los equipos en la Red LAN, la administración
de los usuarios, y el control de los recursos de la red. Una estructura muy utilizada
consiste en varios servidores a disposición de distintos usuarios. Los primeros, por lo
general maquinas más potentes proporcionan servicios como control de impresión,
ficheros compartidos y correo.
La construcción de esta red LAN que permite el acceso a los sistemas de comunicación
si bien está orientada a satisfacer necesidades del medio, específicamente orientado al
cableado estructurado, que además de dejar un gran enriquecimiento intelectual no
ofrece la oportunidad de poner en práctica todos los conocimientos tecnológicos
adquiridos durante la trayectoria de nuestra carrera.
vi
ÍNDICE GENERAL
CAPITULO I PLAN DE INVESTIGACIÓN..................................................................1
1.1 REALIDAD PROBLEMÁTICA........................................................................1
1.2 SELECCIÓN DEL PROBLEMA.......................................................................1
1.3 FORMULACIÓN DEL PROBLEMA................................................................2
1.4 OBJETIVOS.......................................................................................................2
1.4.1 Objetivo General.........................................................................................2
1.4.2 Objetivos Específicos..................................................................................2
1.5 JUSTIFICACIONES..........................................................................................2
1.5.1 Justificación Económica..............................................................................2
1.5.2 Justificación Técnica...................................................................................3
1.5.3 Justificación Operativa................................................................................3
1.5.4 Justificación Social......................................................................................3
1.6 DELIMITACIONES...........................................................................................3
1.7 LIMITACIONES................................................................................................4
CAPITULO II MARCO TEÓRICO.................................................................................5
2.1 FUNDAMENTO DE LOS SISTEMAS DE REDES.........................................5
2.1.1 DEFINICIÓN..............................................................................................5
2.1.2 CLASES......................................................................................................5
2.1.3 Definición..................................................................................................10
2.1.4 Estructura...................................................................................................10
2.1.5 Componentes software..............................................................................34
2.1.6 Selección de un sistema operativo de red..................................................37
2.2 Sistemas operativos de red en entornos multiplataforma.................................39
2.2.1 El entorno multiplataforma........................................................................39
2.2.2 Implementación de soluciones multiplataforma........................................39
2.3................................................................................................................................50
vii
2.4 TRANSMISIÓN DE DATOS..........................................................................50
CAPITULO III LA METODOLOGÍA..........................................................................54
3.1 METODOLOGÍA DEL CICLO DE VIDA DE LOS SERVICIOS DE CISCO
54
3.1.1 Fase de Preparación...................................................................................54
3.1.2 Fase de Planeación....................................................................................55
3.1.3 Fase de Diseño...........................................................................................55
3.1.4 Fase de Implementación............................................................................56
3.1.5 Fase de Operación.....................................................................................56
3.1.6 Fase de Optimización................................................................................56
CAPITULO IV APLICACIÓN DE LA METODOLOGÍA...........................................59
3.2 FASE DE PREPARACIÓN..............................................................................59
3.2.1 Análisis de Requerimientos.......................................................................59
3.3 FASE DE PLANEACIÓN................................................................................59
3.3.1 Aspectos Tomados en Cuenta:..................................................................59
3.4 FASE DE DISEÑO...........................................................................................66
3.4.1 Análisis de los Requerimientos.................................................................66
CONCLUSIONES...........................................................................................................77
RECOMENDACIONES.................................................................................................78
BIBLIOGRAFÍA.............................................................................................................79
viii
CAPITULO I
PLAN DE INVESTIGACIÓN
1.1 DESCRIPCIÓN DEL PROBLEMA
En la ciudad de Huarás, región Ancash, Av. Las Américas 115 está ubicada la
revista “Alma Libertana”, la cual viene desarrollando sus actividades desde el
2006, ésta revista se encarga de publicar artículos científicos, filosóficos,
políticos, deportivos, sociales entre otros de la región Ancash; el personal que
labora en la revista son cinco, cada uno desempeñando diferentes funciones.
Los problemas que presenta la revista “Alma Libertana” son diversos, entre ellos
tenemos: que no hay un registro de los artículos publicados, cuando se necesita
saber si algún autor ha publicado algún artículo la búsqueda es lenta y muchas
veces no se encuentra lo deseado; por otro lado, en cuanto al espacio de
transmisión, solo se centra en la zona de Huarás, estando limitado la difusión en
zonas lejanas como los callejones de los Conchucos, callejón de Huaylas y la
costa de nuestra región; así también, la empresa no ha apuntado hacía las nuevas
generaciones y el mundo tecnológico en el que viven, dejando de lado el uso del
internet, sin tener en cuenta que a éstos ya no les agrada leer en hojas de papel,
por las diferentes incomodidades que presentan estas para el transporte y otras
cosas más; además se observa que la empresa no ha apuntado a la transmisión de
información por medio de las nuevas tecnologías que hoy en día se vienen
empleando y desarrollando, que permiten el acceso al internet desde cualquier
parte del planeta, incluso estando en movimiento de un lado a otro.
9
1.2 SELECCIÓN DEL PROBLEMA
La forma de difundir la información de la revista “Alma Libertana” es muy
restringida en cuanto al espacio geográfico, tampoco se toma en cuenta las
facilidades que otorga el internet y el alcance de las nuevas tecnologías; en cuanto
al procesamiento de la información se ha descuidado el registro de los artículos,
por ello se ha visto por conveniente emplear un medio por el cual se rompa las
barreras geográficas y que permita tener un mayor control con lo que se publica, y
a su vez hacer uso de las tecnologías que hoy en día se encuentran en boga, para
de esta manera incrementar la población de lectores, ya que el objetivo de la
revista es aportar a el mejoramiento de la cultura.
10
1.3 FORMULACIÓN DEL PROBLEMA
¿En qué medida el análisis, diseño y desarrollo de un sistema web utilizando la
técnica Ajax mejorará los procesos de procesamiento y difusión de la información
de la revista Alma Libertana?
1.4 OBJETIVOS
1.4.1 Objetivo General
Analizar, diseñar y desarrollar un sistema web utilizando la técnica Ajax
para mejorar los procesos de procesamiento y difusión de información de la
revista Alma Libertana.
1.4.2 Objetivos Específicos
Aplicar la técnica Ajax en la programación del sistema web.
Precisar los beneficios sociales que acarrea el sistema web.
Usar la notación UML para ejemplificar los modelos de análisis y
diseño.
Emplear como lenguaje de programación PHP y manejador de base de
datos MySQL.
Aplicar como proceso de software el Proceso Unificado de Rational
(RUP).
1.5 JUSTIFICACIONES
1.5.1 Justificación Económica
El implantar el sistema web la revista se difundirá en otra clase de nivel, el
cual no seguirá acarreando gastos de impresión para la difusión de la revis-
ta; por otro lado, los escritores podrán subir directamente sus artículos, evi-
tando errores que se comenten al digitar la revista y de esta manera generan-
do menos egresos, para la corrección.
11
1.5.2 Justificación Técnica
La revista Alma Libertana, cuenta con equipos de cómputo de última
generación y conexión a internet alámbrica, que permitirán la
administración del sistema web, también el sistema web permitirá un
manejo adecuado y eficiente de la información.
1.5.3 Justificación Operativa
El sistema web admitirá difundir masivamente la información de manera
inmediata, es decir que desde cualquier dispositivo que tenga conexión a
internet se podrá subir la información, siempre en cuando cumpla con
algunos requisitos que la empresa proponga.
Por otro lado va a permitir tener un historial de las cosas que se publicaron
en el sistema web, ya sea esta por fechas o autor y así acceder a la
información de manera más rápida.
Así también facilitará la realización de los procesos de difusión de
información de la revista.
Personal capacitado
1.6 LIMITACIONES
No contar con recursos económicos para diferentes gastos.
Tiempo limitado, ya que un trabajo de esta naturaleza lo requiere.
12
CAPITULO II
MARCO TEÓRICO
1.7 LENGUAJES DE PROGRAMACIÓN
1.7.1 PHP
a) Definición
Muñoz, P. (2009) menciona que:
PHP es un lenguaje de programación. Con una sintaxis similar a
los lenguajes C y Perl, que se interpreta por un servidor web Apa-
che y genera código HTML dinámico. Es decir, nos permite crear
un programa que se pueda ejecutar en el servidor desde un pro-
grama visualizador de páginas web y dar respuestas en función de
los datos que introduzca el usuario. El cliente nunca vera el códi-
go del programa PHP, sólo le llegarán las páginas HTML que ge-
nere el programa. A diferencia de JavaScript, que se ejecuta en las
máquinas clientes, un programa PHP se ejecuta en el servidor
web. (p.123).
Así mismo Heurtel, O. (2005) define que:
PHP es un lenguaje de script que se ejecuta en el lado del servi-
dor, cuyo código se incluye en una página HTML clásica. Puede
compararse por tanto a otros lenguajes de script que funcionan se-
gún el mismo principio: ASP (Active Server Pages) o JSP (Java
Server Pages).
13
A diferencia de un lenguaje como JavaScript, en el que el código
se ejecuta en el lado del cliente (en el explorador), el código PHP
se ejecuta en el lado del servidor. El resultado de esta ejecución se
integra en la página HTML, que es enviada al explorador. Este úl-
timo no tiene conocimiento alguno del tratamiento realizado en el
servidor.
Esta tecnología permite realizar página web dinámicas cuyo con-
tenido puede ser completa o parcialmente generado en el momen-
to de la invocación de la página, gracias a la información obtenida
de un formulario o extraída de una base de datos. (p.223).
También Cobo, Gómes, Pérez y Rocha (2009) define que “PHP es un
lenguaje interpretado del lado del servidor que se caracteriza por su po-
tencia, versatilidad, robustez y modularidad. Los programas escritos en
PHP son embebidos directamente en el código HTML y ejecutados por
el servidor web a través de un intérprete antes de trasferir al cliente que
lo ha solicitado un resultado en forma de código HTML puro.” (p.99).
b) Ventajas
Según Muñoz, P. (2009):
PHP presenta múltiples ventajas frente a otros lenguajes de pro-
gramación que necesariamente harán que este lenguaje se impon-
14
ga como una alternativa para el desarrollo de todo tipo de aplica-
ciones.
Interfaz. En primer lugar se ejecuta a través de una interfaz que
le resulta familiar al usuario: el cliente web. No es necesario que
el usuario aprenda nuevas combinaciones de teclas, ni nada pare-
cido, para aprender a usar el programa. Tampoco es necesario te-
ner que instalar ningún software adicional en la estación cliente
para usar un programa PHP a parte del propio navegador web.
De la misma forma, la ejecución de un programa PHP se puede
realizar desde un cliente web de cualquier plataforma: el usuario
puede escoger un sistema operativo y su cliente web preferidos.
Acceso en red. El propio diseño de PHP lleva incorporada esta
virtud. El programa se ejecuta en un servidor al cual se puede ac-
ceder desde cualquier puesto de una red. El servidor siempre po-
dría limitar el acceso a solo determinados puestos y además obli-
gar a la identificación de un usuario para poder acceder a ciertas
partes de un programa.
15
Protección del código. Al tener el código ejecutable albergado en
cliente servidor, este código está protegido tanto de la manipula-
ción de los usuarios como de la presencia de virus.
Cuando configuremos el servidor tenemos que asegurarnos de que
se han tomado las medidas de seguridad necesarias para impedir
accesos indebidos al sistema.
Facilidad de aprendizaje. Es realmente fácil aprender a progra-
mar en PHP. Cualquier persona que sepa algún lenguaje de pro-
gramación puede aprender los fundamentos fácilmente. (p.124).
1.7.2 Java Script
a) Definición
Egea, C. (2000):
Se puede definir mejor diciendo qué NO es JavaScript. En primer
lugar, no es HTML. JavaScript no utiliza etiquetas HTML ni se
atiende a ninguna de las reglas generales del lenguaje HTML. Sin
embargo, se puede usar JavaScript con HTML en una página web.
En segundo lugar, JavaScript no es Java. Aunque a menudo se lla-
ma Java al JavaScript, ambas cosas no son lo mismo. Java fue de-
sarrollado por Sun Microsystems y es un lenguaje de programa-
ción por sí mismo. Por otra parte, JavaScript, fue desarrollado por
Netscape Corporation. Aunque es similar a Java en la sintaxis, Ja-
vaScript no es un lenguaje de programación por sí mismo; para
que funcione debe formar parte de una página web que utilice un
16
navegador que comprenda el lenguaje JavaScript. El lenguaje de
programación Java de Sun puede ser aplicado en una página como
programa de construcción, en tanto que los <<guiones>> (scripts)
de JavaScript dependen del ordenador del cliente (del visitante)
para funcionar. (p. 96).
Así Van, L. (2005) define:
JavaScript es un lenguaje para crear código distinto del lenguaje
HTML. JavaScript es, en cierta forma, un “pequeño” lenguaje de
programación cuyas líneas de código se añaden al lenguaje
HTML. Está inspirado de forma más o menos directa en el len-
guaje C y no plantea problemas de comprensión a quienes ya ten-
gan algunos conocimientos de programación. (…).
Con su filosofía de estructuración del contenido, el lenguaje
HTML nació siendo básicamente estático. Tras su aparición, no
tardó en hacerse sentir la necesidad de añadir algo de movimiento
y, sobre todo, de interactividad con el usuario. Aquí es donde en-
tra JavaScript.
Por ejemplo:
- animar texto o imágenes,
- reaccionar a las acciones de ratón,
- detectar el tipo y la versión del navegador,
- verificar la ortografía al rellenar formularios,
- efectuar cálculos simples a partir de formularios,
- solicitar una confirmación,
17
- presentar la fecha y la hora,
- manejar menús de navegación,
- redirigir al visitante a otra página,
- etc.
El navegador administra y ejecuta directamente las líneas de códi-
go de JavaScript, sin utilizar recursos del servidor que alberga la
página. Esto es lo que se denomina una “aplicación cliente”. Exis-
ten otros lenguajes más evolucionados, como PHP o ASP, que
tratan los datos en el servidor antes de enviarlos en forma de pági-
na HTML al navegador del usuario. Éstas son las “aplicaciones de
servidor”, (…). (p. 176).
Por otra parte Muñoz, P. (2010) menciona que “JavaScript es un len-
guaje de programación desarrollado por Netscape Corporation para su
navegador Netscape Navigator 2.0, para permitir la ejecución de código
dentro de las páginas en HTML. Microsoft posee su propia versión para
su navegador Internet Explorer, llamada JScript, pero que, salvo en al-
gunos detalles generalmente no demasiado importantes, resulta compa-
tible con los navegadores de Netscape.” (p. 97).
b) Ventajas
Según Gutierrez, E. (2009) afirma que:
Gracias a JavaScript, las páginas HTML son más agradables y
disponen de muchas funcionalidades suplementarias.
Saber escribir scripts en JavaScript significa permitir a los usua-
rios de sus páginas HTML el acceso a otras funcionalidades y
18
otros servicios, mejorando de esta manera la profesionalidad de
un sitio web. Incluso recientemente, cuando un internauta escogía
por primera vez un nombre de usuario, era necesario hacer clic
sobre un botón y esperar una respuesta del servidor que en ocasio-
nes solicitaba recomenzar el procedimiento puesto que el nombre
de usuario pertenecía ya a otra persona. En cambio hoy, gracias al
uso de la tecnología AJAX, el control se realiza en un segundo
plano al mismo tiempo que el usuario complementa la ficha. Es
innegable que JavaScript contribuye mucho a la facilidad de uso
de un sitio web e incrementa además la fidelidad del usuario. (p.
13).
Por otro lado Born, G. (2000) manifiesta algunas posibilidades que
ofrecen los scripts:
- A través de los scripts es posible modificar dinámicamente el
documento durante su carga. Las instrucciones de los programas
JavaScript se pueden editar en pantalla con ayuda del navega-
dor.
- Los scripts permiten, igualmente, comprobar los datos de entra-
da de los formularios. El formulario sólo se envía al servidor si
todos los datos son correctos en su forma. Por lo demás, con los
scripts también es posible completar automáticamente determi-
nados datos de los formularios.
- Los scripts pueden reaccionar a eventos (por ejemplo, pulsar un
vínculo con el ratón) y provocar determinadas acciones (por
ejemplo, mostrar una referencia / activar una indicación). El mo-
delo de evento definido en HTML 4.0 permite añadir scripts (lo
cual incluye también a los procedimientos de JavaScript) a los
controles, hipervínculos y otros tipos de elementos. Los procedi-
mientos se ejecutan entonces al producirse determinados eventos
(por ejemplo, señalar, pulsar con el ratón, etc.). (p. 460).
19
1.8 HTML
1.8.1 Definición
Hobbs, L. (1999) “¿qué es HTML? Es un sistema de escritura que compren-
de etiquetas, siendo una etiqueta una instrucción contenida entre corchetes
angulares, por ejemplo, <HTML> es una etiqueta que define el inicio de un
documento en lenguaje HTML. La inmensa mayoría de las etiquetas contie-
nen también una etiqueta de cierre, por ejemplo </HTML> define el final
del documento. El lenguaje HTML se encuentra en continuo desarrollo, por
lo que se le añaden de forma regular nuevas etiquetas que lo hacen más po-
tente y flexible.” (p. 16).
Por otro lado Cobo, A., Gómez, P., et al. (2005) afirma que HTML “(…),
es un lenguaje que permite crear páginas web y para ello utiliza unos co-
mandos o etiquetas que indican o marcan qué se debe mostrar y de qué for-
ma.
Los comandos siempre van incluidos entre los signos < > e insertados en el
propio texto que compone el contenido de la página. Especifican su estruc-
tura (las distintas partes de la página) y forma. Además, permiten la inser-
ción de contenidos especiales como imágenes, videos, sonidos, etc.”(p.53).
Así mismo el Equipo Vértice. (2009) afirma que “HTML es un lenguaje ar-
tificial que los ordenadores son capaces de interpretar y diseñado para que
los programadores redacten instrucciones que los navegadores ejecutan para
originar la página web. Es decir, HTML es un lenguaje de programación, o
un “idioma que la máquina entiende y procesa para dar una respuesta”.
20
(…). Las siglas de HTML significan Hyper Text Markup Language (lengua-
je de marcas de hipertexto). El hipertexto en una computadora es texto que
posee referencias (hipervínculos, links o enlaces) a otro texto. Para simplifi-
car podemos decir que el hipertexto es aquel texto que pulsamos con el ra-
tón del ordenador y nos conduce a otro texto cuando utilizamos Internet.
Pero además de texto, el hipertexto puede estar formado por tablas, imáge-
nes u otros elementos.” (p.12).
1.9 XML
1.9.1 Definición
Sostienen Ramos, I. y Lozano, M. (2000) que “(…). XML es una simplifi-
cación de SGML para el uso general en la Web, que no sustituye a HTML,
sino que lo complementa. Mientras HTML se utiliza para visualizar los da-
tos, XML se usa para representar el dignificado de los datos. Actualmente,
la gran potencialidad de XML hace que existan numerosos comités de ex-
pertos estandarizando extensiones de XML para distintos fines. (…).
XML no es tan sólo un lenguaje de marcado de documentos, es un metalen-
guaje, es decir, un lenguaje para definir lenguajes de marcado. Para. Para
crear un lenguaje de marcado es necesario definir un DTD (Document Type
Definition). Un DTD es la gramática del lenguaje de marcado, es decir, es-
pecifica qué etiquetas pueden o deben encontrarse dentro de otras y en qué
orden, etc.”. (p. 144).
Así también Brochard, J. (2001) sostiene que:
XML es un derivado del SGML. Intenta recoger lo mejor de HTML y de
SGML.
21
Los creadores de XML han pretendido recoger tan sólo los elementos ne-
cesarios para un uso en Internet. Una vez realizados los recortes sólo han
quedado 35 páginas de especificaciones frente a las 155 del SGML, sien-
do el número de páginas directamente proporcional a la complejidad del
lenguaje.
XML debe ser compatible con SGML.
El punto común más importante con SGML es el hecho de que cualquier
documento XML puede estar basado en una DTD. Por tanto no es obliga-
torio que documento XML esté asociado a una DTD.
En un documento XML, el formato de los datos está separado del propio
texto.
XML fue desarrollado inicialmente para Internet, pero gracias a las dis-
tintas DTD a las que puede asociarse, puede servir en la actualidad para
distintas aplicaciones como formato de intercambio o como sistema de
almacenamiento de datos.
El hecho es que es un lenguaje más simple de escritura que su predecesor
el HTML. Es ciertamente más fácil crear los marcadores cuando éstos se
necesitan; en HTML es necesario conocer los marcadores de que dispo-
nemos, así como saber a qué corresponden. Esto tiene el objetivo de ha-
cer comprensible el texto del documento XML por todo el mundo. (p.11).
Por otra parte el Equipo Vértice. (2009) asevera que “un documento XML
es un modelo de datos cuya sintaxis puede parecer similar al HTML, pero
22
que tiene una característica fundamental que lo diferencia de éste: un docu-
mento XML describe el contenido de los elementos que etiqueta. Además el
lenguaje XML separa el contenido del aspecto de una forma total.
Al describir un documento XML, las etiquetas pueden parecerse a las eti-
quetas HTML, con la diferencia de que las etiquetas en XML son etiquetas
creadas por el propio programador definiendo en un documento público, o
en el mismo documento XML, dichas etiquetas y los atributos que van a te-
ner. Esta definición de las etiquetas de un documento XML es lo que se lla-
ma definición de tipo de documento: DTD (Document Type Definitions).
En este DTD se definen las etiquetas, los atributos de cada una de ellas, el
tipo de cada atributo y el contenido de las etiquetas.”. (p. 103).
1.9.2 Ventajas
Lecomte, S. y Boulanger, T. (2009) afirman que “el XML es una alternati-
va eficaz al HTML ya que se adapta mejor a los nuevos entornos cada vez
más complejos (como por ejemplo el comercio electrónico, la mensajería,
etc.). El XML busca, ante todo, separar los datos del formato. A través de la
creación de las hojas de estilo, HTML ha experimentado una notable evolu-
ción. Sin embargo, XML separa los datos de su presentación de manera más
eficaz ya que su principal objetivo es el de almacenar la información y no el
de mostrarla.” (p.18).
Asevera España, M. (2003) que entre las ventajas de XML tenemos:
1. XML representa un estándar abierto, respaldado por un organismo de
normalización internacional (ISO).
2. Las etiquetas XML sustituyen fácilmente a los identificadores de seg-
mento propios de los mensajes UN/EDIFACT a la hora de estructurar
23
los documentos; pero, además, la información transportada puede ser
codificada de una manera mucho más precisa, en una estructura más
rica en matices que la de formatos previos.
3. Las reglas de sintaxis del documento se encuentran ligadas indisolu-
blemente al mismo a través de su definición de tipo de documento
(DTD), de manera que las transacciones son <<autoexplicativas>>.
Ello proporciona mayor dinamismo a las relaciones comerciales, evi-
tando la necesidad de acordar los tipos de mensajes y su estructura
concreta (ej. Concertar los segmentos condicionales utilizados) antes
de dar inicio a los intercambios.
4. Las DTD pueden estar contenidas dentro del documento, como parte
de él, o bien ser una plantilla almacenada en un repositorio. Los repo-
sitorios permiten definir y reutilizar documentos comunes a diversas
organizaciones y procesos de negocio de forma dinámica.
5. Los documentos no son sólo una estructura que contiene datos, sino
que incorporan instrucciones sobre cómo procesarlos o mostrarlos en
pantalla. Basándose en reglas definidas en el propio documento, es
factible guiar este a través de la ruta que debe seguir dentro del flujo
de procesado, por ejemplo, desencadenando o activando determina-
das acciones o eventos. Puesto que el documento transporta los datos
más el código, estos pueden ser tratados como <<objetos de
negocio>>, aplicándose una metodología propia de la programación
orientada a objetos. En cuanto al aspecto que adquieren los documen-
tos al ser mostrados en la pantalla, este es susceptible de especifica-
ción mediante hojas de estilo. En conclusión, el navegador no sólo
presenta los documentos XML, sino que se convierte en un entorno
de ejecución para la aplicación contenida en él.
6. Los hiperenlaces contenidos en los propios documentos permiten en-
lazar a mensajes e información auxiliar incluidos en otras secciones
del mismo documento o almacenados en otros lugares (a los cuales se
hace referencia mediante sus URI).
24
7. La transacción no se centra en el sistema, sino que se organiza en
torno al documento. Las transacciones pueden ser interactivas, en lu-
gar de efectuarse un procesamiento por lotes.
8. Resulta sencillo mantener la compatibilidad con estándares previos;
por ejemplo, es posible incorporar a un documento un mensaje EDI-
FACT completo, como un elemento XML, o bien codificar cada una
de sus partes como elementos XML individuales.
9. Para finalizar, una faceta que merece valorarse es la facilidad de inte-
gración con otras aplicaciones sobre Internet, dada la gran difusión
del formato XML en entornos de índole diversa. (p.639).
1.10 AJAX
1.10.1 Definición
Según Lecomte, S. y Boulanger, T. (2009) “AJAX (Asynchronous JavaS-
cript And XML), en castellano JavaScript asíncrono y XML, es un acrónimo
que representa un conjunto de tecnologías destinadas a la programación
Web. Entre sus tecnologías podemos encontrar: XML, XMLHTTPRequest,
JavaScript y DOM, HTML y CSS.” (p.263).
Con el mismo tenor Orense, M. y Rojas, O. (2010) manifiestan que “AJAX
es una técnica de desarrollo web basada en comunicaciones asíncronas entre
el navegador y el servidor. El intercambio de información se realiza de una
manera no correlativa, lo que hace que se puedan efectuar cambios en pági-
nas web sin necesidad de recarga. Las aplicaciones en AJAX gozan de una
interactividad, rapidez de descarga y usabilidad difícil de conseguir con otro
tipo de aplicaciones.” (p.110).
25
Gutierrez, E. (2009) amplia diciendo que:
Al igual que DHTML, AJAX (Asynchronous JavaScript And XML) es
una mezcla de diferentes técnicas. Con AJAX es posible efectuar recar-
gas de datos que provienen del servidor, mateniéndose siempre en la mis-
ma página. Un visitante puede continuar escribiendo los campos de un
formulario mientras que se efectúa un control en segundo plano para ve-
rificar los datos que se han escrito con los del servidor. Este tipo de fun-
cionamiento, llamado asíncrono, no es el único puesto que la tecnología
AJAX permite igualmente consultar una base de datos en modo síncrono
(en este caso la consulta se ejecuta sin que sea necesario recargar la pági-
na o cargar otra, pero la introducción simultánea de datos es imposible, lo
cual reduce su utilización). En realidad, las páginas escritas con AJAX
usan varias tecnologías:
- El código HTML que se mantiene como el elemento central de la
página, ayudado por la hojas de estilo para la presentación de los
datos.
- El DOM para el acceso a los elementos de la página, sobre todo
con los métodos getElementById o getElementByName.
- El código de programación del lado del servidor, de tipo PHP o
ASP, que permite recuperar la información del servidor como el
objeto XmlHttpRequest que permite controlar la consulta de datos
en el servidor.
- Los datos que se recuperan se presentan bajo la forma de un sim-
ple archivo de texto o JavaScript e incluso XML y deben ser tra-
tados con JavaScript para poder aparecer de manera correcta en la
página. (p.275).
1.10.2 Ventajas
Lecomte, S. y Boulanger, T. (2009) mencionan “Antes de la aparición de
las tecnologías AJAX, los procesos entre cliente y servidor en Internet eran
los siguientes: del lado del cliente, el usuario solicitaba informaciones alma-
26
cenadas del lado del servidor (haciendo clic sobre un vínculo, respondiendo
a un formulario), se enviaba una consulta al servidor, que devolvía una nue-
va página. Estaríamos hablando del modo síncrono.
Hoy en día la utilización de XMLHTTPRequest permite que no sea necesa-
rio realizar todo el proceso descrito anteriormente. Mientras se reciben los
datos solicitados por el usuario, la página consultada se mantiene sin cam-
bios. Una vez se han recibido los datos, sólo se modificarán una parte de la
página gracias a JavaScript, DOM y a CSS. Las consultas XMLHTTPRe-
quest son asíncronas.” (p.263).
Ceballos, J. y Gañán, J. (2010) mencionan que:
Históricamente, las aplicaciones de escritorio siempre han ofrecido una
interacción con el usuario mucho más rica que las aplicaciones web. En
contrapartida, las aplicaciones web no se tienen que instalar, y nos asegu-
ran que los usuarios siempre tienen la última versión de la aplicación, ya
que tan sólo hay que actualizarla una única vez en el servidor.
En cambio, con la aparición de AJAX el tema ha cambiado, ya que es po-
sible crear aplicaciones web que ofrezcan una rica interacción con el
usuario. En realidad, las tecnologías que han habilitado la aparición de
AJAX existen desde hace más de una década, ya que se trata básicamente
de Javascript y XML. No obstante, hasta hace poco que se les ha sacado
todo el partido con aplicaciones como Google Gmail, Microsoft Outlook
Web Access, Flickr, etc.
Al desarrollar una aplicación AJAX, en lugar de diseñarla como una serie
de páginas enlazadas (donde simplemente al acabar de procesar una pági-
na, se muestra la siguiente), se utiliza Javascript para mantener una co-
27
municación asíncrona con el servidor web, y así poder actualizar partes
de las páginas de forma dinámica. (p.109.).
1.11 UML
1.11.1 Definición
Debrauwer, L. y Van der Heyde, F. (2009) definen que “UML (Unified
Modeling Language o lenguaje unificado de modelación) es un lenguaje
gráfico destinado al modelado de sistemas y procesos. Está basado en la
orientación a objetos que condujo, en primer lugar, a la creación de lengua-
jes de programación como Java, C++ o Smalltalk.
UML está unificado, ya que deriva de varias notaciones precedentes. En la
actualidad UML es promovido por el OMG (Object ManaGement Group),
un consorcio de más de 800 sociedades y universidades activas en el campo
de las tecnologías orientadas a objetos.
Nuestra opinión es que UML se convertirá en un lenguaje de modelación
muy extendido, sobre todo gracias a su riqueza semántica, que lo abstrae de
numerosos aspectos técnicos.”(p.13).
Por otro lado Harvey, M. y Deitel , P. (2004) aseveran que “El Lenguaje
Unificado de Modelado es, en la actualidad, un esquema de representación
gráfica ampliamente utilizado para modelar sistemas orientados a objetos.
Unifica los distintos esquemas de notación que existían a finales de la déca-
da de los ochenta. Aquellos que diseñan sistemas utilizan el lenguaje (en la
forma de diagramas) para modelar sus sistemas.
28
Una de las características más atractivas de UML es su flexibilidad. UML se
puede extender y es independiente de los muchos procesos de ADOO. Los
modeladores en UML pueden desarrollar sistemas mediante el uso de distin-
tos procesos, pero todos los desarrolladores pueden expresar dichos sistemas
con un conjunto estándar de notaciones.
El UML es un lenguaje complejo, rico en características gráficas.” (p.19).
Así también Fowler, M. (1999) exponen que “el lenguaje unificado de mo-
delado o UML (Unified Modeling Language) es el sucesor de la oleada de
métodos de análisis y diseño orientados a objetos (OOA&D) que surgió a fi-
nales de la década de 1980 y principios de la siguiente. El UML unifica, so-
bre todo, los métodos de Booch, Rumbaugh (OMT) y Jacobson, pero su al-
cance llegará a ser mucho más amplio. En estos momentos el UML está en
pleno proceso de Estandarización con el OMG (Object Management Group
o Grupo de administración de objetos) y estoy seguro de que se convertirá
en el lenguaje de modelado estándar del futuro.
Decimos, pues, que el UML es un lenguaje de modelado, y no un método.
La mayor parte de los métodos consisten, al menos en principio, en un len-
guaje y en un proceso para modelar. El lenguaje de modelado es la notación
(principalmente gráfica) de que se valen los métodos para expresar los dise-
ños. El proceso es la orientación que nos dan sobre los pasos a seguir para
hacer el diseño.” (p.1).
1.12 Programación Orientada a Objetos
1.12.1 Definición
Rodríguez, C. y Glindo, J. (2009) establecen que:
29
La POO combina la programación estructurada con conceptos nuevos
con el objetivo de descomponer los datos del programa en objetos que
simplifiquen su tratamiento. Un objeto pertenece a un tipo específico
(que aquí se llama clase) y tendrá una serie de datos y una serie de opera-
ciones ( o métodos) definidas sobre todos los objetos de esa clase.
Básicamente, la POO tiene las siguientes características importantes:
1. Encapsulación: Consiste en ocultar las características internas de un
objeto (los datos y el código que los manipula), de forma que sólo se
pueda acceder al objeto a través de las partes declaradas como públi-
cas (usando public en C++). Las partes privadas (private) sólo po-
drán ser accedidas desde el código del propio objeto. Este concepto
está muy relacionado con las características de los tipos de datos abs-
tractos.
2. Polimorfismo o sobrecarga: Consiste en definir varias versiones de
una misma operación y que automáticamente se ejecute la que co-
rresponda según el tipo de situación en la que se requiere dicha ope-
ración. Una forma de implementar esto es la sobrecarga de funcio-
nes. El polimorfismo se puede aplicar a funciones, pero también a
operadores.
3. Herencia: Una clase define las características de un tipo de objeto.
También es posible definir subclases, para que sus objetos hereden
las características de la clase superior. Una subclase también puede
añadir aquellas características que le pertenecen a ella y no a la clase
superior. Esto elimina la tarea de programar las operaciones de una
clase para cada una de sus subclases. (p.151).
Por otra parte Flórez, R. (2005) menciona que “La programación orien-
tada a objetos es realmente un nuevo estilo de programación, el cual, bá-
sicamente consiste en definir clases y poner dichas clases a comunicarse
o conversar entre sí.
30
Una clase es un tipo, la cual tiene asociada las operaciones que se pue-
den ejecutar con objetos de este tipo.
Tipo se refiere a la clase de datos que se pueden almacenar en una varia-
ble en algún lenguaje de programación. Es así, como se pueden definir
variables de tipo entero, real, carácter, etc.” (p.307).
31
CAPITULO III
LA METODOLOGÍA
1.13 RUP
El proceso Unificado de Rational (RUP) es un ejemplo de un modelo de proceso
moderno que proviene del trabajo en el UML y el asociado Proceso Unificado de
Desarrollo de Software. (…). Reúne elementos de todos los modelos de procesos
genéricos, interacciones de apoyo e ilustra buenas prácticas en la especificación y
el diseño.
El RUP reconoce que los modelos de procesos genéricos presentan un solo enfo-
que del proceso. En contraste, el RUP se describe normalmente desde tres
perspectivas:
1. Una perspectiva dinámica que muestra las fases del modelo sobre el tiempo.
2. Una perspectiva estática que muestra las actividades del proceso que se pre-
sentan.
3. Una perspectiva práctica que sugiere buenas prácticas a utilizar durante el
proceso.
La mayor parte de las descripciones del RUP intentan combinar las perspectivas
estática y dinámica es un único diagrama. Esto hace el proceso más difícil de en-
tender, por lo que aquí se utilizan descripciones separadas de cada una de estas
perspectivas.
El RUP es un modelo en fases que identifican cuatro fases diferentes en el proceso
del software. Sin embargo, a diferencia del modelo en cascada donde las fases se
equiparan con las actividades del proceso, las fases en el RUP están mucho más
relacionadas con asuntos de negocio más que técnicos.
32
1. Inicio. El objetivo de la fase de inicio es el de establecer un caso de negocio
para el sistema. Se deben identificar todas las entidades externas (personas y
sistemas) que interactuarán con el sistema y definir estas interacciones. Esta
información se utiliza entonces para evaluar la aportación que el sistema hace
al negocio. Si esta aportación es de poca importancia, se puede cancelar el
proyecto después de esta fase.
2. Elaboración. Los objetivos de la fase de elaboración son desarrollar una com-
prensión del domino del problema, establecer un marco de trabajo arquitectó-
nico para el sistema, desarrollar el plan del proyecto e identificar los riesgos
clave del proyecto. Al terminar esta fase, se debe tener un modelo de los re-
querimientos del sistema (se especifican los casos de uso UML), una descrip-
ción arquitectónica y un plan de desarrollo del software.
3. Construcción. La fase de construcción fundamentalmente comprende el dise-
ño del sistema, la programación y las pruebas. Durante esta fase se desarro-
llan e integran las partes del sistema. Al terminar esta fase, debe tener un sis-
tema software operativo y la documentación correspondiente lista para entre-
garla a los usuarios.
4. Transición. La fase final del RUP se ocupa de mover el sistema desde la co-
munidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un en-
torno real. Esto se deja de lado en la mayor parte de los modelos de procesos
del software pero es, en realidad, una actividad de alto costo y a veces proble-
mática. Al terminar esta fase, se debe tener un sistema software documentado
que funciona correctamente en su entorno operativo.
La iteración dentro del RUP es apoyada de dos formas como se muestra en la fi-
gura. Cada fase se puede representar de un modo iterativo con los resultados desa-
rrollados incrementalmente. Además, el conjunto entero de fases puede también
representarse de forma incremental, como se muestra en la citada figura por la fle-
cha en forma de bucle desde la Transición hasta el Inicio.
33
La vista estática del RUP se centra en las actividades que tienen lugar durante el
proceso de desarrollo. Éstas se denominan flujos de trabajo en la descripción del
RUP. Existen seis principales flujos de trabajo del proceso identificados en el pro-
ceso y tres principales flujos de trabajo de soporte. El RUP se ha diseñado conjun-
tamente con el UML –un lenguaje de modelado orientado a objetos–, por lo que la
descripción del flujo de trabajo se orienta alrededor de los modelos UML asocia-
dos. En la figura NN se describen los principales flujos de trabajo de ingeniería y
de soporte.
La ventaja de presentar perspectivas dinámicas y estáticas es que las fases del pro-
ceso de desarrollo no están asociadas con flujos de trabajo específicos. Al menos
en principio, todos los flujos de trabajo del RUP pueden estar activos en todas las
etapas del proceso. Por supuesto, la mayor parte del esfuerzo se realizará en flujos
de trabajo tales como el modelado del negocio y los requerimientos en las prime-
ras fases del proceso y en las pruebas y despliegue en las fases posteriores.
La perspectiva práctica en el RUP describe buenas prácticas de la ingeniería del
software que son aconsejables en el desarrollo de sistemas. Se recomiendan seis
buenas prácticas fundamentales:
1. Desarrolle el software de forma iterativa. Planifique incrementos del sistema
basado en las prioridades del usuario y desarrollo y entregue las característi-
cas del sistema de más alta prioridad al inicio del proceso de desarrollo.
2. Gestione los requerimientos. Documente explícitamente los requerimientos
del cliente y manténgase al tanto de los cambios de estos requerimientos.
Analice el impacto de los cambios en el sistema antes de aceptarlos.
3. Utilice arquitecturas basadas en componentes. Estructure la arquitectura del
sistema en componentes.
4. Modele el software visualmente. Utilice modelos gráficos UML para presen-
tar vistas estáticas y dinámicas del software.
34
5. Verifique la calidad del software. Asegure que el software cumple los están-
dares de calidad organizacionales.
6. Controle los cambios del software. Gestione los cambios del software usando
un sistema de gestión de cambios y procedimientos y herramientas de gestión
de configuraciones.
El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que re-
presenta una nueva generación de procesos genéricos. Las innovaciones más im-
portantes son la separación de fases y los flujos de trabajo, y el reconocimiento de
que la utilización del software en un entorno del usuario es parte del proceso. Las
fases son dinámicas y tienen objetivos. Los flujos de trabajo son estáticos y son
actividades técnicas que no están asociadas con fases únicas sino que pueden utili-
zarse durante el desarrollo para alcanzar los objetivos de cada fase.
(ps.77 y 78).
35
CAPITULO IV
APLICACIÓN DE LA METODOLOGÍA
1.14 xxx
1.14.1 x.y
CONCLUSIONES
36
RECOMENDACIONES
37
BIBLIOGRAFÍA
Born, Günter (2000). Compendium HTML. Barcelona: Marcombo s.a.
Brochard, J. (2001). XML: Conceptos e implementación. Barcelona: Ediciones ENI.
Ceballos, J. y Gañán, J. (2010). Introducción a .NET. Barcelona: UOC.
Cobo, A., Gómez, P., Perez, D. y Rocha, R. (2005). PHP y MySQL. España: Díaz de
Santos.
Debrauwer, L. y Van der Heyde, F. (2009). UML 2: edición. Barcelona: Ediciones ENI.
Egea García, Carlos (2000). Diseño web para tod@s II. Barcelona: Icaria editorial s.a.
Flórez, R. (2005). Algoritmos, estructuras de datos y programación orientada a objetos.
Bogotá: Ecoe.
Fowler, M. (1999). UML gota a gota. México: PEARSON.
Gutierrez, E. (2009). JavaScript: conceptos básicos y avanzados. Barcelona: Ediciones
ENI.
Harvey, M. y Deitel , P. (2004). Java: cómo programar. México:PEARSON.
Heurtel, O. (2009). PHP y MySQL. Barcelona: Ediciones ENI.
Hobbs, Lilian (1999). Diseñar su propia página web. Barcelona: MARCOMBO S.A.
Lecomte, S. y Boulanger, T. (2009). XML práctico: bases esenciales, conceptos y casos
prácticos. Barcelona: Ediciones ENI.
Orense, M. y Rojas, O. (2010). SEO: cómo triunfar en buscadores. Madrid: ESIC.
Ramos, I. y Lozano, M. (2000). Ingeniería del software y bases de datos. España:
Universidad Castilla – La Mancha.
Rodríguez, C. y Glindo, J. (2009). Aprendiendo C. España: Universidad de Cádiz.
Van Lancker, Luc (2005). CSS en DHTMl: javascript aplicado a hojas de estilo.
Barcelona: Ediciones ENI.
Muñoz Rodríguez, Pedro (2010). Mantenimiento de portales de información. Madrid:
Vision libros.
España, M. (2003). Servicios Avanzados de telecomunicaciones. Madrid: Ediciones
Díaz de Santos S. A.
38
ANEXOS
39