1.1.

BASES TERICAS
Para el desarrollo de la investigacin es necesario describir los distintos fundamentos relacionados.

1.1.1. PROCESO UNIFICADO DE RATIONAL (RUP)

Un proceso define quien est haciendo que, y cuando, adems dice como Alcanzar un determinado objetivo. En la ingeniera de software el objetivo Es construir un producto de software [Jacob, 2000], vale decir, que todos los Proyectos necesitan de un proceso que guie sus actividades. Segn Jacobson en sus libros El procesos Unificado de desarrollo de Software, unos procesos efectivos proporcionan normas para el desarrollo eficiente de Software de calidad, captura y presenta las mejores prcticas que la tecnologa permite. Por tanto reduce el riesgo y hace el proyecto ms predecible (ver Figura. 1.1).

Figura 1.1 Proceso de Desarrollo de software

Entre muchos investigadores de la orientacin a objetos hay tres autores que se han destacado por sus contribuciones al uso del paradigma en todo el proceso de desarrollo: Ivar Jacobson, Grady Booch y James Rumbaugh. Luego de muchos aos de trabajo individual desarrollado y difundido sus propios mtodos, han unido sus teoras y su experiencia, y se han puesto a la cabeza de un formidable grupo de investigadores para contribuir dos herramientas con las cuales buscan estandarizar y por ende facilitar el uso de los objetos en la programacin: El lenguaje Unificado de Modelo (UML Unified Modeling

Language) y el proceso unificado rotacional para el desarrollo de programas(RUP, Rational Unified Process ) mientras que UML, es ya un lenguaje maduro que ha logrado la aceptacin de amplios sectores de las industria y la academia, RUP sigue siendo an una propuesta que deber depurarse y templarse al calor de la experiencia de su aplicacin en el campo y los portes de los casos de estudio [Jacob,2000] (ver Figura. 1.2).
Figura 1.2 Historial de Procesos Unificados

RUP y UML estn estrechamente relacionados entre s, pues mientras el primero establece las actividades y los criterios para conducir un sistema desde su mximo nivel de abstraccin, el segundo ofrece la notacin grafica necesaria para representar los sucesos, modelos, que se obtienen de procesos de refinamiento. RUP se define como un proceso dirigido por:

Casos de Uso Centrado en la Arquitectura Iterativo e Incremental

A. DIRIGIDO POR CASOS DE USO

Procesos de desarrollo de software utiliza los casos de uso como una herramienta para la obtencin de requisitos de usuario. Donde los casos de uso son para definir la funcionalidad del sistema, y guan al desarrollador en la construccin de la arquitectura del sistema. La descripcin obtenida de los requerimientos debe ser comprendida por casos de uso que nos ayudan a recopilar la informacin acerca de la interaccin que tiene los usuarios en este caso actores con el sistema. Un caso de uso es una secuencia, reacciones que el sistema lleva a cabo para ofrecer un resultado de Valor a algn actor, que sirven para realzar pruebas sobre los componentes desarrollados (ver Figura.1.3). Los casos de uso enlazan los flujos de trabajo fundamentales. El proyecto progresa a travs de estos flujos de trabajo, que inician en los casos de uso [Jacob 2000].
Figura 1.3 Caso de uso que en laza los flujos de trabajo fundamental

B. CENTRADO EN LA ARQUITECTURA En el caso de software la arquitectura se refiere a un conjunto de decisiones significativas acerca de la organizacin de un sistema, la eleccin de los elementos acerca de la organizacin de un sistema software, la seleccin de los elementos estructurales a partir de las cuales se componen el sistema con su respectivo comportamiento y las interacciones entre esos elementos y la composicin de esos elementos estructurales.

La necesidad de una arquitectura radica en poder comprender el sistema, es decir que todos los que estn involucrados con su desarrollo deben entender el problema al cual va enfocado el sistema de software para satisfacer las demandas individuales y

de la organizacin mediante la utilizacin de los diagramas definidos por UML.

La organizacin es un punto muy importante ya que cuanto mayor sea la organizacin del proyecto software mayor ser la comunicacin entre los desarrolladores para coordinar sus esfuerzos dividiendo el sistema en subsistemas definiendo las interfaces correctas de diseo. Al conocer el dominio de problema y con qu componentes se piensa en como conectar esos componentes para cumplir con los requisitos del sistema y realizar los modelos de casos de uso reutilizando dichos componentes. En la arquitectura de la construccin, antes de construir un edificio, este se completa desde varios puntos de vista: estructura, condiciones elctricas, fontanera, etc.

C. ITERATIVO E INCREMENTAL

Jacobson en su libro El Proceso Unificado de Desarrollo de Software, explica que en esta fase proporciona la estrategia para desarrollar un producto de software en pasos pequeos manejables:

a) Planificar un poco b) Especificar, disear e implementar un poco c) Integrar, probar y ejecutar un poco cada iteracin. Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencial de un sistema a travs de mltiples ciclos de desarrollo de anlisis, diseo implementacin y pruebas.

El modelo incremental entrega el software en partes pequeas pero utilizables, llamadas incrementos [Press, 1998]. En

general, cada incremento se construye sobre aquel que ha sido entregado. Las ventajas de un desarrollo de software con un ciclo de vida iterativo se dan gracias a la retroalimentacin en cada ciclo por lo cual se crea un sistema ms robusto. En cada incremento que y tiene el sistema se va perfeccionando a un ms, lo cual permite al usuario realizar las modificaciones requeridas en el transcurso del tiempo [Press, 1998].

Todo sistema informtico complejo supone un gran esfuerzo que puede Durar desde varios meses hasta anos, por lo tanto, lo ms prctico es Decidir en varias fases. Actualmente se puede hablar de ciclos de vida en los que se realiza varios recorridos por todas las fases.

Todos los sistemas informticos complejos suponen de un gran esfuerzo que puede durar desde varios meses hasta a nos; por lo tanto, lo ms practico es dividirla en varias fases. Actualmente se puede hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina iterativo del proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Adems cada iteracin parte de la anterior incrementado o revisando la funcionalidad

implementada. Se suele denominar proceso (ver Figura 1.4).

Figura 1.4 Proceso Unificado e Incremental

1.1.2. LENGUAJE DE MODELADO UNIFICADO (UML)

UML, emergi en los '90 luego de la bsqueda de un lenguaje de modelamiento que unificara a la industria, que sigui a la "guerra de mtodos" de los '70 y '80. A pesar de que UML evolucion primeramente de varios mtodos orientados al objeto de segunda generacin (en nivel de notacin), UML no es simplemente un lenguaje para modelamiento orientado al

objeto de tercera generacin. Su alcance extiende su uso ms all de sus predecesores. Y es la experiencia, experimentacin y una gradual adopcin del estndar lo que revelar su verdadero potencial y posibilitara a las organizaciones darse cuenta de sus beneficios.

1.1.2.1.

FUNCIONES

Son acciones o procesos a ser realizados para lograr alcanzar un objetivo que presenta el proyecto. Las funciones pueden ser organizadas de dos tipos.

Tabla 2.1 Categora de las Funciones

CATEGORIA

DE LA

FUNCIN EVIDENTE

SIGNIFICADO Debe realizarse y el usuario debera saber que se ha realizado Debe realizarse, aunque no es visible para el usuario. Esto

OCULTA

hace muchos servicios tcnicos subyacentes , como guardar informacin en un mecanismo persistente

Fuente: [LARMAN, 1999]

A. DIAGRAMAS DE CASOS DE USO

Los casos de uso no son propiamente un caso de anlisis, se limitan a describir Procesos de dominio que pueden expresarse en forma narrativa en un formato estructurado de prosa y

pueden ser eficaces en un proyecto de tecnologa no orientada a objetos. No obstante, constituyen un paso preliminar muy til porque describen las especificaciones de un sistema. [Jacob, 2000]

A) ACTORES

El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. Por lo

regular, estimula el sistema con eventos de entrada o recibe algo de l. Los actores estn representados por el papel que desempean en el caso: Cliente, tcnico u otro. Conviene escribir su nombre con mayscula en la narrativa del caso para facilitar la identificacin (ver Figura 2.5).

Figura 2.5 Actor

Fuente: [LARMAN, 1999]

B) CASO DE USO

El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso [Jacob, 2000]. Los

casos de uso, son historias o casos de utilizacin de un sistema, no son exactamente los requerimientos, ni las especificaciones funcionales, sino que ejemplifican e incluyen tcticamente los requerimientos en Las historias que narran (ver Figura. 2.6).Figura 2.6

Caso de Uso

Fuente: [LARMAN, 1999]

c) RELACIN
Si un caso de uso inicia o contiene el comportamiento de otro se dice que usa el segundo caso, eso es una relacin unidireccional [Jacob 92]. Esta relacin puede presentar uno de los siguientes tipos:

La relacin usa, se utiliza cuando se quiere reflejar un comportamiento comn en varios casos de uso (ver Figura. 2.7).

La relacin extiende, se utiliza cuando se requiere reflejar un comportamiento opcional de un caso de uso, es decir, es cuando tiene un caso similar a otro, cuyo contexto tiene mucho ms detalle.

Figura 2.7 Relacin de usos

Fuente: [Larma, 1999]

B. DIAGRAMA DE SECUENCIAS
El diagrama de secuencia es un tipo de diagrama de interaccin cuyo objetivo es describir el comportamiento dinmico del sistema de informacin haciendo nfasis en la secuencia de los mensajes intercambiados por los objetos [Jacob, 2000].

El diagrama de secuencia tiene

dos

dimensiones,

el

eje

vertical representa el tiempo y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior hacia el interior, cada objeto tiene asociado una lnea de vida y focos de

control. La lnea de vida indica el intervalo de tiempo durante el que existe ese objeto. Un foco de control o activacin muestra el periodo de tiempo (ver Figura. 2.8).

Figura 2.8 Diagrama de Secuencia

Fuente: [Jacob, 2000]

C. DIAGRAMA DE COLABORACIN

El diseo orientado a objetos tiene como primicia definir las especificaciones lgicas del software que cumplan con los requisitos funcionales, un paso esencial de esta fase es la asignacin de responsabilidades entre los objetos y mostrar cmo interactan a travs de mensajes, expresados en diagramas de elaboracin, cuyo objetivo es describir el

comportamiento dinmico de informacin, como interactan los objetos entre s, con que otros objetos tienen vinculados o intercambian mensajes a un determinado objeto.

Un diagrama de colaboracin muestra la misma informacin que un diagrama de secuencia, pero de forma diferente. En los diagramas de colaboracin coexiste una secuencia temporal en el eje vertical es decir, la colaboracin de los mensajes en el diagrama no indica cual es el orden en el que sucede.

Adems la colaboracin de los objetos es ms flexible y permite mostrar de forma ms clara cules son las colaboraciones entre ellos. D. DIAGRAMA DE CLASES

Es la representacin de los aspectos estticos del sistema, utilizando diversos mecanismos de abstraccin (clasificacin, generalizacin, agregacin). El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus relaciones con los dems objetos, pero no muestran informacin temporal [Ferre, 2005].

Se advierten los siguientes tipos de relacin:

1. La Asociacin que representan un conjunto de enlaces entre objetos o instancias de clases.

2. Herencia que indica que una subclase hereda los mtodos y atributos especificados por una superclase heredad los mtodos por ende la subclase, adems de poseer sus propios mtodos y atributos poseer a las caractersticas y atributos visibles de la superclase.

3. La agregacin que es un tipo de relacin jerrquica entre un objeto que representa la totalidad de ese objeto y las partes que la componen. Permite el agrupamiento fsico de estructuras relacionadas lgicamente.

En el siguiente ejemplo se muestran las distintas clases relacionadas entre s:

Se muestra la asociacin entre la clase TREE (rbol) y la clase NODE (nodo), es decir la asociacin que existe

entre ambas, y la cardinalidad de uno a muchos que significa que un rbol tiene n nodos.

La herencia que se da entre las clases Personavalue, StringValue, cuyo padre seria la clase VALUE, dando a entender que existe un valor (value) en comn que puede heredarse de la clase padre. Y de la misma forma se da con las clases KEY, PersonaKey, StrKey

Cabe la importancia de notar que en la clase PersonaKey y StrKey estn denotados los mtodos y atributos que debera tener toda clase.

Figura 2.9 Diagrama de Clases

Fuente: [Ferre, 2005]

E. DEFINICIN DEL ESQUEMA DE BASE DE DATOS

Consiste en determinar el esquema de base de datos que se utilizar , en este caso se vio conveniente el estudio de bases de datos objeto -relacionales. En la generalidad de las aplicaciones es necesario guardar y

recuperar la informacin en un mecanismo de almacenamiento persistente, una base de datos relacional por ejemplo. Dado el predominio de estas ltimas, a menudo se requiere su uso en vez de otras bases ms manejables orientadas a objetos. De ser as, surgen varios problemas a causa de la desigualdad

entre representaciones de datos orientadas a registros, y las que se orientan a objetos, se requieren servicios especiales de ambos tipos en las bases de datos relacionales [Larma, 1999]. Cmo mapear un objeto a un archivo o a un esquema de base de datos relacional? El patrn de representacin de objetos a tablas propone definir una tabla para cada clase de objeto persistente. Los atributos de objetos que contienen tipos

primitivos de datos (nmero, booleano, cadena y otros) se mapean en las columnas. [Larma, 1999]. Conviene contar con un medio que relacione los objetos con los registros y de asegurarse de que la repeticin de la materializacin de un registro no culmine en la duplicacin de objetos. El patrn identificador de objetos (IDO) se propone asignar un IDO a cada registro y objeto (o al agente de un objeto). Un identificador de objetos suele ser un valor

alfanum rico, es nico para un objeto en especfico, toda tabla de base de datos relacional tiene un IDO como clave primaria, y los objetos tambin contarn (directa o indirectamente) con un identificador [Larma, 1999]. Si todos los objetos se asocian a un IDO y si todas las tablas poseen una clave primaria IDO los objetos podrn mapearse de modo singular en una regin de alguna tabla.

Cmo representar las relaciones de objetos en una tabla de una base de datos relacional? La respuesta se da en el patrn de representacin de las relaciones de objetos como tablas que propone lo siguiente: Asociacin uno a uno Colocar una clave fornea de identificador de objetos en una o en las dos tablas que representan los objetos en la relacin. Crear una tabla asociativa que registre los identificadores de objetos de cada relacin. Asociaciones de uno a muchos, una coleccin por ejemplo Crear una tabla asociativa que registre los identificadores de cada objeto en la relacin. Asociaciones de muchos a muchos Crear una tabla asociativa que registre todos los identificadores de objetos en la relacin

1.1.3. APLICACIONES WEB

1.1.3.1.

ARQUITECTURA DE APLICACIONES WEB

El trmino arquitectura de aplicacin es usado en el diseo de aplicaciones, habitualmente del tipo cliente-servidor. En el diseo fsico se especifica exactamente donde se encontraran las piezas de la aplicacin. En el diseo lgico o conceptual se especifica la estructura de la aplicacin y sus componentes sin tomar en cuenta donde se localizara el software, hardware e infraestructura. Tales conceptos incluyen el orden de procesamiento, mantenimiento y seguimiento comunes en sistemas organizacionales. Muchas veces se toma demasiado en cuenta el diseo fsico de una aplicacin. Por aadidura los desarrolladores generalmente asumen, indebidamente, que el diseo lgico se corresponde punto a punto con el diseo fsico. Contrario a esto, un diseo

adecuado debera permitir su implantacin en varias plataformas y configuraciones. Como se puede ver, esta caracterstica de portabilidad es un punto deseable para permitir que su aplicacin sea flexible y escalable.

1.1.3.2.

MODELO CLIENTE / SERVIDOR

El paradigma cliente / servidor es uno de los ms extendidos dentro de los servicios a travs de red. Este trmino, en su ms amplia definicin, se usa para describir una aplicacin en la cual dos o ms procesos separados trabajan juntos para completar una tarea. El proceso cliente solicita al proceso servidor la ejecucin de alguna accin en particular. Esta operacin se conoce como proceso cooperativo, dado que dos procesos separados cooperan para completar la tarea en particular.

Figura 2.10: Modelo cliente / servidor

La Figura 2.1 muestra el funcionamiento de este modelo. Se puede ver como el cliente realiza peticiones al servidor, mientras que el servidor se dedica simplemente a responderle. De por s, el servidor tiene un papel pasivo por lo que necesita que un cliente le demande algo. Los principales servicios de Internet (WWW, FTP, SMTP, etc.) tienen clientes y servidores

especficos, aunque en tiempos recientes se intente integrar todo bajo una interfaz web que es ms amigable para el usuario.

Los procesos pueden o no estar en una sola mquina fsica. Tales procesos en una aplicacin cliente/ servidor pueden localizarse en la misma mquina o separados fsicamente. El diseo o lgico, y no el fsico, es el que determina en qu grado una aplicacin es cliente / servidor.

1.1.3.3.

APLICACIONES WEB

La idea fundamental de los navegadores, browsers, es presentar documentos escritos en HTML que han obtenido de un servidor web. Estos documentos HTML habitualmente presentan

informacin de forma esttica, sin ms posibilidad de interaccin con ellos. El modo de crear los documentos HTML ha variado a lo largo de la corta vida de las tecnologas web pasando desde las primeras pginas escritas en HTML almacenadas en un fichero en el servidor web hasta aquellas que se generan al vuelo como respuesta a una accin del cliente y cuyo contenido vara segn las circunstancias. Adems, el modo de generar pginas dinmicas ha

evolucionado, desde la utilizacin del Common Gateway Interface (CGI), hasta los servlets pasando por tecnologas tipo JavaServer Pages (JSP). Todas estas tecnologas se encuadran dentro de aquellas conocidas como Server Site, ya que se ejecutan en el servidor web. Con la extensin de Internet y de la web en concreto, se han abierto infinidad de posibilidades en cuanto al acceso a la informacin desde casi cualquier sitio. Esto representa un desafo a los desarrolla- dores de aplicaciones, ya que los avances en tecnologa demandan cada vez aplicaciones ms rpidas, ligeras y robustas que permitan utilizar la web.

Figura 2.11: Pasos en el modelo cliente / servidor Afortunadamente, se dispone de herramientas potentes para alcanzar este objetivo, ya que han surgido nuevas tcnicas que permiten que el acceso a una base de datos desde la web. El nico problema es decidir entre el conjunto de posibilidades la correcta para cada situacin. El protocolo CGI ha cumplido con el propsito de aadir interactividad a las pginas web pero sus deficiencias en el desarrollo de aplicaciones y en la escalabilidad de las mismas ha conducido al desarrollo de nuevas Application Programming Interface (API) especficas de servidor. Para aprovechar el potencial de estas tecnologas y ofertar una solucin de servidor ms extensible y portable, Sun posee la tecnologa llamada servlet. Los servlets Java son eficientes, debido al esquema de threads en el que se basan y al uso de una arquitectura estndar como la Java Virtual Machine (JVM).

Otra nueva tecnologa viene a sumarse a las que extienden la funcionalidad de los servidores web, llamada JSP. Los JSP permiten unir HTML, aplicaciones Java, y componentes

JavaBeans creando una pgina web especial que el servidor web compila dinmicamente en un servlet la primera vez que es llamada.

Figura 2.12: Esquema general de las tecnologas Web Otro aspecto que completa el panorama son, las inclusiones del lado del cliente, Client Side, que se refieren a las posibilidades de que las pginas lleven incrustado cdigo que se ejecuta en el cliente, como por ejemplo JavaScript.

El esquema general de la situacin se puede ver en la Figura 2.3, donde se muestran cada tipo de tecnologa involucrada en la generacin e interaccin de documentos web.

1.1.3.4.

ARQUITECTURA DE 3 NIVELES

La llamada arquitectura en 3 niveles es la ms comn en sistemas de informacin que, adems de tener una interfaz de usuario, contemplan la persistencia de los datos.

Una descripcin de los tres niveles seria la siguiente: Nivel 1: Presentacin ventanas, informes, etc.

Nivel 2: Lgica de la Aplicacin. Tareas y reglas que gobiernan el proceso. Nivel 3: Almacenamiento mecanismo de almacenamiento.

Figura 2.13: Arquitectura de 3 niveles

1.1.3.5.

LENGUAJES

Para la creacin de aplicaciones web se utilizan mltiples lenguajes. En este caso, se han utilizado diferentes lenguajes de programacin web como pueden ser HTML, PHP o JavaScript

A. HYPER TEXT MARKUP LANGUAGE (HTML)

El Hyper Text Markup Language (HTML) [Specification, 2004], es un lenguaje de marcado, diseado para estructurar textos y definir su presentacin en forma de hipertexto, que es el formato estndar de las pginas web. Gracias a Internet y a los navegadores del tipo Mozilla, Firefox, Netscape o Explorer, el HTML se ha convertido en uno de los formatos ms populares que existen para la construccin de documentos.

Contrariamente a otros lenguajes de programacin, el HTML utiliza etiquetas o marcas, que consisten en breves instrucciones de comienzo y final, mediante las cuales se determina la forma con la que deben aparecer el texto, as como las imgenes y los dems elementos, en la pantalla del ordenador.

B. CASCADING STYLE SHEETS (CSS)

Las hojas CSS son un lenguaje formal usado para definir la presentacin de un documento estructurado escrito en HTML. El World Wide Web Consortium (W3C) [Consortium, 2004], es el encargado de formular la especificacin de las hojas de estilo que servir de estndar para los navegadores. La idea que se encuentra detrs del desarrollo de CSS es separar la estructura de un documento de su presentacin Por ejemplo, el elemento de HTML H1 indica que un bloque de texto es un encabezamiento y que es ms importante que un bloque etiquetado como H2. Cuando se utiliza CSS, la etiqueta H1 no debera proporcionar informacin sobre cmo va a ser visualizado, solamente marca la estructura del documento. La informacin de presentacin se proporciona separada en una hoja de estilo con la que se especifica cmo se ha de mostrar: color, fuente, alineacin del texto y tamao, adems puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. Las ventajas de utilizar CSS son: Control centralizado de la presentacin de un sitio web completo, con lo que se agiliza de forma considerable la actualizacin del mismo. Los navegadores permiten a los usuarios especificar su propia hoja de estilo local, que ser aplicada a un sitio web remoto, con lo Por que aumenta considerablemente la

accesibilidad.

ejemplo,

personas con deficiencias

visuales podran configurar su propia hoja de estilo para aumentar el tamao del texto o remarcar ms los enlaces.

Una pgina puede disponer de diferentes hojas de estilo segn el dispositivo que la muestre o incluso a eleccin del usuario. Por ejemplo, para ser impresa o mostrada en un dispositivo mvil.

El documento HTML en s mismo es ms claro de entender y se consigue reducir considerablemente su tamao.

Hay varias versiones: CSS1 y CSS2, con CSS3 en desarrollo por el W3C. Los navegadores modernos implementan CSS1 de forma completa, aunque existe pequen as diferencias de implementacin dependiendo del navegador.

C. JAVASCRIPT
JavaScript [Eich, 2001], es un lenguaje interpretado orientado a las pginas web basado en el paradigma prototipo, con una sintaxis semejante a la del lenguaje Java. El lenguaje JavaScript se integra dentro del cdigo HTML de las pginas web y acta en cuanto un evento (un click en un boto, por ejemplo) es ejecutado. El lenguaje que fue inventado por Brendan Eich en la empresa Netscape Communications, aparecio por primera vez en el Netscape Navigator 2.0. Tradicionalmente, se vena utilizando en pginas web HTML, para realizar tareas y operaciones en el marco de la aplicacin cliente / servidor.

Figura 2.14: JavaScript

Los autores inicialmente lo llamaron Mocha y, ms tarde, LiveScript, pero fue rebautizado como JavaScript en un anuncio conjunto entre Sun Microsystems y Netscape, en 1995. En 1997, los autores propusieron JavaScript para que fuera adoptado como estndar internacional the European Computer

Manufacturers Association. (ECMA). En junio de 1997, fue adoptado como un estandar ECMA, con el nombre de ECMAScript. Poco despus tambin lo fue como un estndar ISO.

Para evitar estas incompatibilidades, el World Wide Web Consortium (W3C) diseo el estndar Document Object Model (DOM), que incorporan los navegadores actuales.

D. HYPERTEXT PREPROCESSOR (PHP)

PHP [PHP, 2004], es un lenguaje Open Source interpretado de alto nivel, especialmente pensado para desarrollos web usado para generar pginas HTML. La mayora de su sintaxis es similar a C, Java y Perl y es fcil de aprender. La meta de este lenguaje es permitir el desarrollo de pginas web, pginas dinmicas de una manera rpida y fcil, aunque su versatilidad hace que pueda emplearse en otros muchos mbitos.

Figura 2.15: PHP En el invierno de 1998, poco despus del lanzamiento oficial de PHP 3.0, Andi Gutmans y Zeev Suraski comenzaron a trabajar en la reescritura del ncleo de PHP. Los objetivos de diseo fueron mejorar la ejecucin de aplicaciones complejas, y la modularidad del cdigo El nuevo motor, apodado Motor Zend [Zend, 1999] (comprimido de sus apellidos, Zeev y Andi), alcanz estos objetivos de diseo satisfactoriamente, y se introdujo por primera vez a mediados de 1999. PHP 4.0, basado en este motor, fue oficialmente liberado en mayo de 2000. Esta versin incluye otras caractersticas clave

como el soporte para la mayora de los servidores web y sesiones HyperText Transfer Protocol (HTTP). Hoy en da, se estima que PHP es usado por cientos de miles de programadores y muchos millones de sitios informan que lo tienen instalado, sumando ms del 20 % de los dominios en Internet. Adems su equipo de desarrollo incluye docenas de programadores, trabajando en el ncleo o en proyectos relacionados con PHP como PEAR y el proyecto de

documentacin. Actualmente tiene soporte para cosas tan dispares como Simple Object Access Protocol (SOAP), eXtensible Markup Language

(XML), Sockets, DB, OpenSSL o llamadas POSIX.

1.1.3.6.

AUTENTICACIN

Un sistema de autenticacin es un mdulo de seguridad para asegurar que el usuario que visita las pginas es quien dice ser. Por supuesto, conociendo a ese usuario, se le podr dar acceso a ms aspectos de la pgina que si fuese un usuario desconocido o annimo. En la Figura 2.9 se muestra el proceso de autenticacin, donde se pide un usuario y una contrasea para acceder a la aplicacin de acceso restringido. Una vez que se tienen los datos de autenticacin (usuario y contrasea a escritos en la pgina inicial), se hace una comprobacin de los mismos y, se redirecciona al navegador a la pgina de la aplicacin restringida, en caso de que sean correctos, o a la pgina del login donde se volver a pedir el usuario y la contrasea, en caso de que sean incorrectos. La aplicacin de acceso restringido, aparte de mostrar las funcionalidades que se quieren proteger con usuario y contrasea a, debe de realizar unas comprobaciones de seguridad para saber si se ha pasado con xito el proceso de autenticacin o si se est intentando acceder de manera no permitida a esa pgina.

Figura 2.17: Autenticacin del usuario

A. ATAQUES TPICOS
De todos los ataques, existen dos que son especialmente peligrosos: la inyeccin de SQL y la suplantacin de identidad. 1. SUPLANTACIN DE IDENTIDAD Para evitar la repeticin de la contrasea, se almacenan las credenciales en la sesin del usuario en forma de token (espacio de almacenamiento temporal en el servidor). A partir de ese momento, el navegador manda un identificador de sesin (en la URL o como cookie) para usarla. Este ataque consiste en robar la sesin de un usuario autenticado, es decir, ese identificador y usarlo para acceder a la aplicacin con las credenciales del usuario. 2. INYECCIN DE CDIGO SQL La inyeccin SQL consiste en la modificacin del

comportamiento de las consultas mediante la introduccin de parmetros no deseados en los campos a los que tiene acceso el usuario.

Este tipo de errores puede permitir a usuarios malintencionados acceder a datos a los que de otro modo no tendran acceso y, en el peor de los casos, modificar el comportamiento de las aplicaciones. El acceso restringido se basa en una tabla de usuarios y contrasea y solo los usuarios que se validen contra esa tabla podrn acceder a esos contenidos. Una manera de que los usuarios se validen ser mostrar un formulario pidiendo el usuario y la contrasea y una vez que se rellenan esos campos enviar esos datos a la base de datos para comprobar si es vlido.

Figura 2.18: Suplantacin de identidad

Si el usuario escribe por ejemplo admin y de contrasea cualquier otra cosa, la sentencia no devolver registros y no se permitir entrar a esa persona. Pero qu ocurre si el usuario escribe or 1=1 como usuario y lo mismo de contrasea? En este caso la variable Consulta contendr la cadena:

SELECT Count(*) FROM

Usuarios WHERE

Usuario = or

1=1 AND password = or 1=1 Y obviamente esta sentencia devuelve registros con lo que el usuario entrara en la web sin tener permiso. Pero es an peor si el usuario utiliza estos mecanismos de inyeccin de SQL para ejecutar cdigo arbitrario en el servidor: sentencias DDL, cambio de permisos, utilizar procedimientos almacenados y un largo etctera. Como solucin, hay varios sistemas para evitarlo. Por ejemplo se puede filtrar las entradas de los usuarios reemplazando la Aparicin de por (dos comillas simples) e incluso evitando que los usuarios puedan pasar caracteres como / o cualquier otro que se nos ocurra que puede causar problemas. Otro factor importante en cuanto a la seguridad es limitar al mximo los permisos del usuario que ejecuta estas sentencias para evitar posibles problemas. Por ejemplo utilizando un usuario distinto para las sentencias SELECT, DELETE, UPDATE y asegurndonos que cada ejecucin de una sentencia ejecute una sentencia del tipo permitido.

1.1.3.7.

BASES DE DATOS

El trmino base de datos fue acuado por primera vez en 1963, en un simposio celebrado en California. De forma sencilla, una base de datos no es ms que un conjunto de informacin relacionada que se encuentra agrupada de forma estructurada. El archivo por s mismo, no constituye una base de datos, sino ms bien la forma en que est organizada la informacin es la que da origen a la base de datos. Las bases de datos manuales pueden ser difciles de gestionar y modificar. Por ejemplo, en una gua de telfonos no es posible encontrar el nmero de un individuo si no se sabe su apellido, aunque se conozca su domicilio. Del mismo modo, en un archivo de pacientes en el que la informacin esta ordenada por el nombre, ser una tarea complica- da encontrar todos los pacientes que viven en una

zona determinada. Todos estos problemas se pueden resolver mediante el uso de una base de datos informatizada. Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista ms formal, se puede definir una base de datos como un conjunto de datos estructurados, fiables y homogneos, organizados independientemente en mquina, accesibles en tiempo real, y que son compartidos por usuarios concurrentes que tienen necesidades de informacin diferente y no predecible en el tiempo. Estas colecciones de datos que cumplen las siguientes propiedades:

a.

Estn estructurados independientemente de las aplicaciones y del soporte de almacenamiento que los contiene.

b. c.

Presentan la menor redundancia posible. Pueden ser compartidos por varios usuarios y/o aplicaciones.

A. SISTEMA GESTOR DE BASES DE DATOS (SGBD) Los sistemas gestores de bases de datos son un tipo de software muy especfico, dedicado a servir de interfaz entre la base de datos (almacenamiento fsico en disco) y el usuario, o las aplicaciones que la utilizan. Se compone de: Lenguaje de definicin de datos. Una vez finalizado el diseo de una base de datos y escogido un SGBD para su implementacin, el primer paso consiste en especificar el esquema conceptual, el esquema interno de la base de datos, y la correspondencia entre ambos. En muchos SGBD no se mantiene una separacin estricta de niveles, por lo que el administrador de la base de datos y los diseadores utilizan el mismo lenguaje para definir ambos esquemas: el Lenguaje de definicin de datos (LDD). El SGBD posee un compilador de LDD cuya funcin consiste en procesar las sentencias del lenguaje para identificar las

descripciones de los distintos elementos de los esquemas y almacenar la descripcin del esquema en el catlogo o diccionario de datos. Se dice que el diccionario contiene metadatos: describe los objetos de la base de datos. Lenguaje de manipulacin de datos. Una vez creados los esquemas de la base de datos, los usuarios necesitan un lenguaje que les permita manipular los datos de la base de datos: realizar consultas, inserciones, eliminaciones y

modificaciones. Este lenguaje es el que se denomina LMD.

Hay dos tipos de Lenguaje de manejo de datos (LMD):

Procedurales No Procedurales

B. STRUCTURED QUERY LANGUAGE (SQL) La historia de SQL [Chamberlin, 1996], empieza en 1974 con la definicin, por parte de Donald Chamberlin y de otras personas que trabajaban en los laboratorios de investigacin de International Business Machines (IBM), de un lenguaje para la especificacin de las caractersticas de las bases de datos que adoptaban el modelo relacional. Este lenguaje se llamaba Structured English Query Language (SEQUEL) cuyo primer prototipo, llamado SEQUEL-XRM, fue implementado entre 1974 y 1975. Los experimentos con ese prototipo condujeron, en los aos siguientes a una revisin del lenguaje (SEQUEL/2), que a partir de ese momento cambio de nombre por motivos legales, convirtindose en SQL. El prototipo (System R), basado en este lenguaje, se adopt y utilizo internamente en IBM y lo adoptaron algunos de sus clientes elegidos. Gracias al xito de este sistema, que no estaba todava comercializado, tambin otras compaas

empezaron a desarrollar sus productos relacionales basados en SQL.

A partir de 1981, IBM comenz a entregar sus productos relacionales y en 1983 empez a vender DB2. En el curso de los aos ochenta, numerosas compaas (por ejemplo Oracle y Sybase) comercializaron productos basados en SQL, que se convierte en el estndar industrial de hecho por lo que respecta a las bases de datos relacionales. En 1986, el ANSI adopto SQL como estndar para los lenguajes relacionales y en 1987 se transform en estndar ISO. Esta versin del estndar se denomin SQL/86. En los aos siguientes, ste ha sufrido diversas revisiones que han conducido, primero, a la versin SQL/89 y, posteriormente, a la actual SQL/92. El hecho de tener un estndar definido por un lenguaje para bases de datos relacionales abre potencialmente el camino a la intercomunicabilidad entre todos los productos que se basan en l. Efectivamente, en general cada productor adopta e implementa en la propia base de datos solo el corazn del lenguaje SQL (el as llamado Entry level o al mximo el Intermediate level), extendindolo de manera individual segn la propia visin que cada cual tenga del mundo de las bases de datos. Actualmente, est en marcha un proceso de revisin del lenguaje por parte de los comits ANSI e ISO, que debera terminar en la definicin de lo que en este momento se conoce como SQL3. Las caractersticas principales de esta nueva versin de SQL deberan ser su transformacin en un lenguaje standalone y la introduccin de nuevos tipos de datos ms complejos que permitan, por ejemplo, el tratamiento de datos multimedia.

C. SQLITE
SQLite es un sistema de gestin de bases de datos relacional compatible con ACID, y que est contenida en una relativamente pequea librera en C. SQLite es un proyecto de dominio pblico creado por D. Richard Hipp. A diferencia de los sistemas de gestin de base de datos clienteservidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de eso, la librera SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a travs de llamadas simples a subrutinas y funciones. Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son ms eficientes que la comunicacin entre procesos. El conjunto de la base de datos (definiciones, tablas, ndices, y los propios datos), son guardados como un solo fichero estndar accesible en el sistema de ficheros. La librera implementa la mayor parte del estndar SQL92, incluyendo transacciones de base de datos atmicas,

consistencia de base de datos, aislamiento, y durabilidad (ACID), triggers y la mayor parte de las consultas complejas.

Figura 2.19: SQLite

D. MODELADO DE DATOS
De acuerdo a Ullman [Ullman, 1999], un modelo de datos es un sistema formal y abstracto que per- mite describir los datos de acuerdo con reglas y convenios predefinidos. Es formal pues los objetos del sistema definidas se y manipulan utilizando siguiendo reglas los

perfectamente

exclusivamente

operadores definidos en el sistema, independientemente de lo que estos objetos y operadores puedan significar.

Segn Silberschatz [Silberschatz, 1998], un modelo de datos es una combinacin de tres componentes 1. Una coleccin de estructuras de datos, los bloques constructores de cualquier base de datos que conforman el modelo. 2. Una coleccin de operadores o reglas de inferencia, los cuales pueden ser aplicados a cualquier instancia de los tipos de datos listados en el punto anterior, que permiten consultar o derivar datos de cualquier parte de estas estructuras en cualquier combinacin deseada

3. Una coleccin de reglas generales de integridad, las cuales, explcita o implcitamente, definen un conjunto de estados consistentes estas reglas algunas veces son expresadas como reglas de insertar-actualizar-borrar

En paralelo al diseo del sistema se ha desarrollado el modelo de base de datos.

Modelo entidad / relacin

Los diagramas entidad / relacin [Chen, 1976], a veces denominado por su siglas E-R, son una herramienta para el modelado de datos de un sistema de informacin. Estos diagramas expresan entidades relevantes para un sistema de informacin, sus interrelaciones y propiedades. Los diagramas E-R son un lenguaje grafico para describir conceptos. Informalmente, son simples dibujos o grficos que describen la informacin que trata un sistema de informacin y el software que lo automatiza. Los elementos de dicho lenguaje (Figura 3.2) se describen a continuacin, por orden de importancia

Figura 2.20: Elementos de modelo entidad / relacin

Entidades: Una entidad es cualquier objeto discreto sobre el que se tiene informacin. Se representa mediante un rectngulo o caja etiquetada en su interior mediante un nombre (Figura 3.2a). Ejemplos de entidades habituales en los sistemas de informacin son: factura, persona, albarn, empleado, etc. Relaciones: Una relacin describe cierta interdependencia (de cualquier tipo) entre una o ms entidades. Se representa mediante un rombo etiquetado en su interior mediante un verbo (Figura 3.2b). Adems, dicho rombo debe unirse mediante lneas con las entidades que relaciona. Una relacin no tiene sentido sin las entidades que relaciona. Por ejemplos una persona (entidad) trabaja (relacin) para un departamento (entidad). Las relaciones entre dos entidades se denominan binarias, las relaciones entre tres entidades se denominan ternarias, y las relaciones entre cuatro o ms entidades se denominan mltiples. Las relaciones mltiples son poco frecuentes, mientras que las relaciones binarias son habituales en cualquier problema.

Los atributos describen informacin til sobre las entidades. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un empleado de otro es su nmero de la Seguridad Social. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementarle en una base de datos. Simplificacin de relaciones mltiples en binarias, o ternarias en los casos apropiados. Normalizacin de relaciones (algunas relaciones pueden

transformarse en atributos y viceversa). Conversin a tablas (en caso de utilizar una base de datos relacional. Este caso se ver ms detenidamente en el siguiente punto).

E. SEGURIDAD EN LA BASE DE DATOS Las bases de datos normalmente son accedidas por varios usuarios por lo que el SGBD debe proporcionar tcnicas que permitan restringir a algunos usuarios o grupos de usuarios el acceso a determinadas partes de la base de datos. Esto es especialmente importante cuando se trata de organizaciones que cuentan con una gran base de datos que almacena los datos de distintas secciones de la organizacin. Para ello, los SGBD suelen contar con un subsistema de seguridad y autorizacin que asegura la seguridad de la base de datos frente accesos no autorizados. Estos mecanismos de seguridad suelen ser de dos tipos: Mecanismos de seguridad discrecionales. Permiten conceder privilegios a los usuarios de la base de datos. Mecanismos de seguridad obligatorios. Permiten definir varios niveles de seguridad para los objetos de la base de datos, de forma que los usuarios pueden utilizar solo los elementos que estn en su nivel de seguridad o inferior.

Otro problema de seguridad es el de evitar que personas no autorizadas tengan acceso al SGBD. El mecanismo de seguridad de un SGBD debe incluir formas que permitan restringir el acceso al sistema, esa funcin se denomina control de acceso y est basado en el uso de cuentas de usuario. El administrador de la base de datos (DBA) es la persona responsable de la base de datos y entre sus obligaciones se encuentra la de conceder privilegios a los usuarios que necesitan utilizar el sistema. El DBA tiene una cuenta de superusuario que ofrece privilegios no disponibles para las cuentas

convencionales. Entre estos privilegios se encuentran el de creacin de cuentas, concesin y revocacin de privilegios, y asignacin de niveles de seguridad. De esta forma, todas las personas que deseen acceder a la base de datos, tendrn que solicitar al DBA la creacin de una cuenta de usuario con un nombre de usuario y una contrasea. El usuario utilizara estos datos y podr acceder a la base de datos siempre que el SGBD valide dicha conexin. El SGBD podr guardar todas las operaciones que se realicen sobre la base de datos, de forma que se puedan detectar anomalas en el acceso o en la modificacin de los datos. Estas operaciones son guardadas en el registro del sistema (log) y el nmero de entradas correspondientes a operaciones realizadas sobre la base de datos depender del grado de detalle con el que se quieran registrar las operaciones sobre la base de datos.