SISTEMA DE GESTIÓN DISTRIBUIDA

DEL PATRIMONIO CULTURAL

BAJO INTERNET

ALUMNO: JOSÉ CELANO MARTÍN

TUTORES: ANTONIO OCÓN CARRERAS Y ENRIQUE RUBIO ROYO

U.L.P.G.C.
INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS
PROYECTO FIN DE CARRERA
Para sitas y sitos…
 AGRADECIMIENTOS

Ha sido de inestimable ayuda para este proyecto las colaboraciones técnicas de mis amigos y
compañeros de profesión Emilio y Yeray. Asimismo han mostrado una gran predisposición y
cooperación la F.E.D.A.C. (Fundación para la Etnografía y el Desarrollo de la Artesanía
Canaria) y el Servicio de Patrimonio Histórico del Cabildo de Gran Canaria sin cuyo apoyo
no habría sido posible este proyecto.
 ÍNDICE

PRÓLOGO..............................................................................................................................12
1. Objetivos del proyecto.........................................................................................................14
1.1. Objetivos del trabajo.....................................................................................................14
1.2. Objetivos académicos...................................................................................................14
2. Material y medios necesarios...............................................................................................15
2.1. Medios materiales.........................................................................................................15
2.2. Software........................................................................................................................15
3. Contenido de la memoria.....................................................................................................16
CONTEXTO JURÍDICO-ADMINISTRATIVO....................................................................18
4. Introducción.........................................................................................................................20
4.1. ¿Qué es patrimonio cultural?........................................................................................20
4.2. Medidas para la conservación.......................................................................................20
4.3. Medidas legislativas. Evolución histórica.....................................................................21
4.4. Ley 16/1985, de 25 de junio, del Patrimonio Histórico Español..................................23
4.4.1. Bienes que integran el patrimonio histórico español.............................................24
4.4.2. El Registro de Bienes de Interés Cultural..............................................................26
4.4.3. El Inventario General.............................................................................................27
4.5. Ley 4/1999, de 15 de marzo, de Patrimonio Histórico de Canarias (B.O.C. nº 36, de
24/03/99)...............................................................................................................................28
4.5.1. Objeto y finalidad...................................................................................................29
4.5.2. Constitución del patrimonio histórico de Canarias................................................29
4.5.3. Clasificación...........................................................................................................29
4.5.4. Competencias en la administración del patrimonio histórico................................30
4.5.5. Protección del Patrimonio Histórico de Canarias..................................................32
4.5.6. Registro Canario de Bienes de Interés Cultural.....................................................33
4.5.7. Inventario de Bienes Muebles................................................................................33
CONTEXTO TECNOLÓGICO..............................................................................................34
5. Ingeniería del software.........................................................................................................36
5.1. Modelo lineal secuencial...............................................................................................36
5.1.1. Análisis de los requisitos de usuario y del software...............................................37
5.1.2. Diseño....................................................................................................................37
5.1.3. Generación de código.............................................................................................37
 5.1.4. Pruebas...................................................................................................................38
5.1.5. Mantenimiento.......................................................................................................38
5.2. Modelo de construcción de prototipos..........................................................................38
5.3. El modelo incremental..................................................................................................38
5.4. Ingeniería web...............................................................................................................39
APLICACIÓN WEB...............................................................................................................41
6. Sistema de Gestión del Patrimonio Cultural........................................................................43
6.1. Contexto jurídico-administrativo..................................................................................43
6.2. Contexto tecnológico....................................................................................................44
7. Antecedentes. Análisis del sistema actual............................................................................45
7.1. Inventario Insular Etnográfico......................................................................................45
7.2. Inventario Insular Arqueológico y Arquitectónico........................................................46
8. Objetivos..............................................................................................................................49
9. Planificación.........................................................................................................................51
9.1. Planificación temporal..................................................................................................51
10. Investigación......................................................................................................................53
10.1. Investigación del dominio del problema.....................................................................53
10.2. Investigación técnica...................................................................................................53
11. Análisis...............................................................................................................................55
11.1. Definición del problema..............................................................................................55
11.2. Análisis de requisitos de usuario.................................................................................55
11.3. Documento de requisitos de usuario...........................................................................55
11.4. Análisis de requisitos de software...............................................................................56
11.5. Documento de requisitos de software.........................................................................56
12. Diseño................................................................................................................................57
12.1. Estudio preliminar.......................................................................................................57
12.1.1. Tecnologías web...................................................................................................58
12.1.2. Framework para aplicaciones web......................................................................60
12.1.3. Arquitectura MVC................................................................................................61
12.1.4. STRUTS, phpMVC y sQeletor, frameworks.......................................................63
12.1.5. Motores de plantillas............................................................................................67
12.1.6. Motores de persistencia........................................................................................67
12.2. Diseño de la arquitectura.............................................................................................71
12.2.1. PC.........................................................................................................................74
12.2.2. Arquitectura distribuida........................................................................................88
12.2.3. phpMVC y sQeletor.............................................................................................95
 12.2.4. PerenQen..............................................................................................................98
13. Justificación y evaluación de las herramientas utilizadas................................................103
14. Pruebas y resultados.........................................................................................................105
14.1. Páginas estáticas........................................................................................................107
14.2. Páginas dinámicas.....................................................................................................109
15. Documentación.................................................................................................................117
16. Implantación del sistema..................................................................................................119
16.1. Requisitos para la instalación....................................................................................119
16.2. Instalación.................................................................................................................119
16.3. Implantación..............................................................................................................121
16.4. Mantenimiento..........................................................................................................121
16.5. Costes de explotación................................................................................................121
17. Conclusiones....................................................................................................................123
18. Trabajo futuro...................................................................................................................125
19. Bibliografía y referencias.................................................................................................127
I. ANEXO. Modelo de datos de inventarios insulares del sistema actual..............................129
I.1. Ficha de bien etnográfico.............................................................................................129
I.2. Ficha de bien arqueológico..........................................................................................132
I.3. Ficha de bien arquitectónico........................................................................................135
II. ANEXO. Documento de especificaciones de la aplicación..............................................138
II.1. Conceptos...................................................................................................................138
II.2. Tipos de usuario (grupos o roles)...............................................................................138
II.3. Tipos de privilegios....................................................................................................138
II.4. Actividades.................................................................................................................138
II.4.1. PC_CONSULTOR_MINIMO.............................................................................139
II.4.2. PC_CONSULTOR...............................................................................................139
II.4.3. PC_EDITOR........................................................................................................139
II.4.4. PC_SUPERVISOR..............................................................................................139
II.4.5. PC_ADMINISTRADOR.....................................................................................139
III. ANEXO. Modelo del software.........................................................................................140
III.1. Diagramas de paquetes..............................................................................................140
III.2. Diagramas de clases del software.............................................................................141
III.2.1. PC.......................................................................................................................141
III.2.2. PerenQen............................................................................................................152
III.3. Diagramas se secuencia............................................................................................153
III.3.1. PC.......................................................................................................................153
 III.3.2. phpMVC.............................................................................................................155
III.3.3. PerenQen............................................................................................................166
IV. ANEXO. Frameworks para aplicaciones web..................................................................168
IV.1. phpMVC....................................................................................................................168
IV.2. Phrame.......................................................................................................................168
IV.3. WACT........................................................................................................................168
IV.4. eocene........................................................................................................................169
IV.5. Ambibalence..............................................................................................................169
IV.6. Krysalis......................................................................................................................169
IV.7. Ismo...........................................................................................................................169
IV.8. BinaryCloud..............................................................................................................171
IV.9. Mojavi.......................................................................................................................171
IV.10. Horde.......................................................................................................................171
IV.11. PHITE......................................................................................................................171
IV.12. Blueshoes.................................................................................................................172
IV.13. Cake PHP................................................................................................................172
IV.14. phpwebtk.................................................................................................................172
IV.15. studs.........................................................................................................................172
V. ANEXO. Motores de persistencia para PHP.....................................................................173
V.1. Metastorage.................................................................................................................173
V.2. Propel..........................................................................................................................174
V.3. DA_Data_object.........................................................................................................176
V.4. POG............................................................................................................................177
V.5. Cake PHP....................................................................................................................178
 PRÓLOGO

"Poéticamente habita el hombre la tierra."

Johann Christian Friedrich Hölderlin (1770-1843)

La esencia del hombre es la necesidad de crear. Esta es una de las interpretaciones de la cita
de Hölderlin. "El hombre es un apetito perpetuo de ser otro" (Octavio Paz), "de inventar
posibilidades en la realidad o incluso de crear realidades" (José Antonio Marina).

La informática es la nueva actividad inteligentemente creadora de realidades. De esta manera,

un programa, se convierte en la visión subjetiva de la realidad que tiene un programador, y en
consecuencia, un programador se convierte en creador, una persona que actúa y se refleja en
el resto de los hombres a través de comprender y modelar sus actividades.

Debido al alcance e influencia de la informática en la sociedad actual en todos los ámbitos, al

menos en los países "desarrollados", el hombre a delegado su actividad innata creadora en la
tecnología, y los informáticos como representantes de esta, tenemos la responsabilidad de
devolver el ser humano al hombre, o por lo menos hacer un intento desde nuestra posición
privilegiada de intermediario entre el ordenador y la persona. El reto futuro es descubrir
cómo, y una de las claves puede estar como siempre en la educación, y más a corto plazo en
compartir esta tecnología y hacerla accesible a todos. Hemos de intentar que no se convierta
,como muchas veces lo ha sido, en una actividad o recurso elitista que genere una nueva
forma de marginación, sino en una plataforma de soporte para el hombre, y no una plataforma
que el hombre tenga que soportar.

Dentro de este contexto se desarrolla el presente proyecto con la intención de crear una
plataforma de unión, no unificación, para la conservación del patrimonio cultural, que es la
huella de la actividad creadora del hombre, y por lo tanto de su esencia, a lo largo de la
historia.

En Las Palmas a 20 de noviembre de 2003.

El autor.
1. Objetivos del proyecto

1.1.Objetivos del trabajo

Desarrollar una aplicación para la gestión de los inventarios de bienes inmuebles de carácter
etnográfico, arqueológico y arquitectónico que permita:

• Contener y gestionar los inventarios insulares de las siete islas del archipiélago
canario.

• Poner a disposición de cualquier usuario los inventarios para su consulta desde

cualquier punto de acceso a la web.

• Gestionar los inventarios (altas, bajas y modificaciones) desde cualquier punto de

acceso a la web.

1.2.Objetivos académicos

Con el desarrollo de este proyecto fin de carrera el alumno cubrirá los siguientes objetivos de
formación:

• Aprendizaje en la programación de sistemas.

• Aprendizaje de proceso, métodos y herramientas de ingeniería del software.

• Aprendizaje en el desarrollo de aplicaciones web mediante frameworks.

• Aprendizaje en el manejo de sistemas de bases de datos.

• Aprendizaje el la documentación de software.

2. Material y medios necesarios

2.1.Medios materiales

Fue necesario para el desarrollo de este proyecto un ordenador con las siguientes
características:

• Procesador: AMD Athlon 64 a 2,21 GHz.

• Memoria: 1GB de memoria RAM.
• Disco duro: 160 GB a 7.200 r.p.m.

También fue indispensable disponer de una conexión a Internet.

2.2.Software

El software utilizado durante el trabajo fue:

• Sistema operativo Windows XP.

• Servidor web Apache 1.3.
• Lenguaje de programación PHP 4.3.9.
• Sistema de gestión de bases de datos PostgreSQL 8.0.
• Librerías para PHP: PEAR, Smarty y PHPLayersMenu.
• Motor de persistencia PerenQen para PHP.
• Frameworks para aplicaciones web en PHP: phpMVC y sQeletor.
• Entorno de desarrollo Eclipse 3.0 con el plugin para PHP.
• Paquete ofimático Microsoft Office 2003 para la generación de la documentación y de
las gráficas de las pruebas.
• Generador de documentación de código phpDocumentor 1.2.3.
• Aplicación para tratamiento gráfico Adobe Photoshop 7.0 para el diseño de la interfaz
de la aplicación web.
• Programa para el modelado de diagramas de UML MagicDraw 10.0.
3. Contenido de la memoria
Este proyecto consiste en un estudio en profundidad de la gestión informatizada del
patrimonio cultural histórico, y el desarrollo de un sistema basado en una aplicación web para
el inventariado de dicho patrimonio.

La memoria está estructurada en tres bloques: contexto jurídico-administrativo, el contexto

tecnológico y la aplicación web.

El la primera parte se describe extensamente el contexto jurídico y administrativo en el que se

enmarca el software que se pretende construir. Se introduce al lector en las entidades
relacionadas con la gestión del patrimonio, en el ámbito nacional y autonómico.

En la segunda parte se explica el proceso de desarrollo del software desde el punto de vista
ingenieril, orientado al tipo de tecnología y de aplicación que se va a construir.

En la tercera y última parte se detallan todas las fases de desarrollo del producto, y se
describen pormenorizadamente las características del sistema. Esta parte está estructurada
intencionadamente en la secuencia en que se desarrolla la producción del software, para de
esta manera remarcar los pasos necesarios para la creación de una aplicación web.
 PARTE I

CONTEXTO JURÍDICO-ADMINISTRATIVO
4. Introducción

4.1.¿Qué es patrimonio cultural?

Antes de abordar cualquier tema que concierna al patrimonio cultural es de obligada
necesidad plantearse la cuestión de hasta dónde abarca el concepto de patrimonio cultural.
Aunque podría parecer trivial, esta pregunta conlleva una serie de dificultades y su respuesta
se ha visto modificada a lo largo de la historia legislativa de este país. Una definición muy
genérica podría ser la siguiente:

Conjunto de bienes de interés artístico, histórico y cultural.

Como vemos, de esta definición surge rápidamente una cuestión sobre cuál será el
criterio a usar para determinar el interés de un bien. A lo largo del siglo han ido aumentando el
número de objetos que se incluyen en este conjunto desde los más evidentes como edificios
monumentales o cuadros de gran valor hasta objetos de interés paleontológico u otros objetos
de uso común como muebles o herramientas de trabajo.

En este texto utilizaremos la definición que da la Ley de 1985 de Patrimonio Histórico

(en adelante LPH85), la más reciente de ámbito nacional y que en su artículo 1.2 dice:

"Integran el Patrimonio Histórico Español los inmuebles y objetos muebles de interés

artístico, histórico, paleontológico, arqueológico, etnográfico, científico o técnico. También
forman parte del mismo el patrimonio documental y bibliográfico, los yacimientos y zonas
arqueológicas así como los sitios naturales, jardines y parques, que tengan valor artístico,
histórico o antropológico."

En nuestro ámbito regional la Ley 4/1999, de 15 de marzo, de Patrimonio Histórico de

Canarias (en adelante LPHC99) indica que el patrimonio histórico de Canarias está
constituido por "Bienes muebles e inmuebles que tengan interés histórico, arquitectónico,
artístico, arqueológico, etnográfico, paleontológico, científico o técnico" y que además
"también forman parte del patrimonio histórico canario los bienes inmateriales de la cultura
popular y tradicional y las particularidades lingüísticas del español hablado en Canarias."

4.2.Medidas para la conservación

Existen varios tipos de medidas a tomar para la protección del patrimonio cultural:
Medidas educativas: debido a la gran cantidad de patrimonio cultural de que dispone nuestro
país se hace casi imposible controlarlo y protegerlo todo, por lo tanto, la única forma
realmente efectiva de conservar todo ese patrimonio sea quizás concienciar a la sociedad de
que se trata de un bien común, y de que es responsabilidad de todos su conservación.

Medidas de promoción y difusión: la mayoría de la gente involucrada en la conservación del

patrimonio coincide en la necesidad de dar un papel activo al patrimonio. Que no se convierta
en una carga pesada que todos debamos soportar con los impuestos, sino por el contrario en
un valor capaz de generar beneficios no solamente sociales sino incluso económicos. Además
coinciden en la necesidad de realizar una divulgación seria hecha por profesionales y que el
patrimonio no se convierta, como sucede con frecuencia, en un mero reclamo publicitario de
otras industrias como el turismo.

Medidas económicas: la administración pública actúa básicamente de dos formas en lo que a

medidas económicas se refiere. Por un lado determina la cantidad de dinero que se destina en
los presupuestos a la conservación del patrimonio cultural y por otro lado puede incentivar
una serie de medidas fiscales que favorezcan la conservación de los bienes pertenecientes a
propietarios privados.

Medidas legislativas: la actual ley contempla una serie de sanciones contra las exportaciones
ilegales, daños a bienes, etc.

4.3.Medidas legislativas. Evolución histórica.

[71 D.C.] Ya en el año 71 D.C. Vespasiano prohíbe el despojo de los elementos suntuarios de
los edificios.

[1263] En el código de las 7 Partidas, código legislativo creado por Alfonso X para lograr la
unidad legislativa de sus reinos, se establece que no se deben hacer casas ni edificios cerca de
los muros de las villas y castillos, ni hacer casas ni torres ni otros edificios cerca de las
iglesias.

[1926] Real Decreto-Ley 9 de agosto de 1926 sobre protección, conservación y

acrecentamiento de la riqueza artística. Se trata del "primer cuerpo normativo que de un
modo sistemático y coherente intenta proteger a la totalidad del patrimonio".
[1933] Ley de 13 de mayo de 1933 del Patrimonio Artístico Nacional.
"Surge como consecuencia del artículo 45 de la Constitución republicana de 1931. La Ley de
1933, que estuvo en vigor algo más de cincuenta años, supone, en algunos aspectos, un
retroceso en cuanto a la de 1926. Así, en el concepto de Patrimonio Histórico-Artístico se
vuelve a recuperar los valores históricos y artísticos para su definición, aunque delimita su
campo de aplicación a los bienes que tengan más de cien años de antigüedad. No obstante,
abre las expectativas para la incorporación de obras contemporáneas, aunque siempre bajo
el reconocimiento de su historicidad o artisticidad. Por lo que se refiere a las novedades, esta
se adapta a las recomendaciones y criterios de carácter internacional que se habían
establecido en la Carta de Atenas, dos años antes."

[1970] Convención de la UNESCO, contra la importación, exportación y transferencia de

propiedades ilícitas de bienes culturales.

[1978] La Constitución española de 1978.

En su artículo 33 hace referencia a reconocer el "derecho a la propiedad privada y a la
herencia" y señala que "la función social de estos derechos delimitará su contenido, de
acuerdo con las leyes y nadie podrá ser privado de sus bienes y derechos sino por causa
justificada de utilidad pública o interés social", planteando de esta manera una nueva
concepción del concepto absolutista de propiedad.

En su artículo 44 dice: "Los poderes públicos promoverán y tutelarán el acceso a la cultura,

a la que todos tienen derecho."

Artículo 46.1 "Los poderes públicos garantizarán la conservación y promoverán el

enriquecimiento del legado histórico cultural y artístico de los pueblos de España y de los
bienes que lo integran, sitos en su territorio, cualquiera que sea su régimen jurídico y su
titularidad. La ley penal sancionará los atentados contra ese patrimonio."

Artículo 46.2 "El Patrimonio Nacional es una unidad indivisible, cuyos bienes serán
inalienables e imprescribibles. Su régimen y administración serán objeto de una ley".

[1985] La Ley de Patrimonio Histórico Español de 1985.

Surge principalmente a causa de de la dispersión normativa que hacía complicadísima su
coordinación, por la creciente preocupación sobre esta materia por parte de la comunidad
internacional y de sus organismos representativos y por la nueva distribución de competencias
entre el Estado y Comunidades Autónomas. Los objetivos básicos de la ley son:

“El primer deber y preocupación ha de ser conservar, mantener y proteger esos bienes.
El segundo objetivo de la ley es el acrecentamiento.
El tercer objetivo de la ley es la transmisión a las generaciones futuras del Patrimonio
Histórico Español.”

[1999] Ley 4/1999, de 15 de marzo, de Patrimonio Histórico de Canarias.

Se crea con la finalidad de proteger, conservar, restaurar, acrecentar, investigar, difundir,
fomentar y transmitir en las mejores condiciones posibles a las generaciones futuras el
patrimonio histórico de Canarias, así como su disfrute por los ciudadanos como objeto
cultural y educativo y de su aprovechamiento como recurso económico, en tanto tales usos
armonicen con la referida finalidad.

4.4.Ley 16/1985, de 25 de junio, del Patrimonio Histórico Español

A continuación se profundizará un poco en el contenido de la LPH85, ya que ha servido
como marco jurídico sobre el que se soporta y fundamenta cualquier actuación de las
instituciones públicas encaminada a la gestión y administración de los bienes culturales. Esta
tarea servirá para situar el sistema informático que se generó en este proyecto dentro del
contexto de realidad que pretende modelar, ya que naturalmente existe un sistema previo
implantado que queremos mejorar. En este sentido la informática solo es una herramienta,
como se comenta en el prólogo, que modela la realidad para poder llevar a cabo las tareas que
se realizan en esta de una forma más eficiente y eficaz. También se pretende resaltar las
entidades, sus interrelaciones y las actividades que aparecen en la ley, porque serán las que
luego se habrán de plasmar en el sistema informático que se desarrolle.

Existen otras leyes regionales que afectan al patrimonio cultural como son la LPHC99. Para
el desarrollo de este proyecto se ha empleado básicamente la del 85 de ámbito nacional para
generar un sistema genérico válido para cualquier territorio nacional. No obstante, debido a la
localización de realización del proyecto y a que las principales fuentes para el análisis de
requisitos del sistema han sido de la Comunidad Autónoma Canaria, y más exactamente de
Gran Canaria, se ha añadido un apartado que hace referencia a la LPHC99, para explicar con
un poco más de detalle las peculiaridades de las gestión del patrimonio en Canarias.
De la LPH85 nos interesan principalmente dos cosas de cara a este proyecto. Por un lado el
tipo de bienes que integran el patrimonio histórico español y por otro lado las herramientas
administrativas utilizadas para su gestión.

4.4.1.Bienes que integran el patrimonio histórico español

En cuanto a la clasificación de los bienes que integran el patrimonio histórico español la ley
hace la siguiente clasificación en función de la movilidad de los bienes:

4.4.1.1.Bienes inmuebles
De interés cultural: Ya sean declarados por ministerio de la Ley o declarados por real
Decreto de forma individualizada.

Clases: Monumento, Jardín histórico, conjunto histórico, sitio histórico (paraje natural) y
zona arqueológica.

4.4.1.2.Bienes muebles
De interés cultural: Declarados por ministerio de la Ley o declarado por Decreto de forma
individualizada.

No declarados de interés cultural; pero con singular relevancia.

La ley añade varios títulos más específicos para los siguientes tipos de bienes:

4.4.1.3.Patrimonio arqueológico
"Lo constituyen los bienes muebles e inmuebles, de carácter histórico susceptibles de ser
estudiados con metodología arqueológica, hayan sido o no extraídos y tanto si se encuentran
en la superficie o en el subsuelo, en el mar territorial o en la plataforma continental. Forma
parte, asimismo, de este patrimonio, los elementos geológicos y paleontológicos relacionados
con la historia del hombre y sus orígenes y antecedentes."

4.4.1.4.Patrimonio etnográfico
"Lo integran los bienes muebles e inmuebles y los conocimientos y actividades que son o han
sido expresión relevante de la cultura tradicional del pueblo español en sus aspectos
materiales, sociales o espirituales."

Bienes inmuebles: "Aquellas edificaciones e instalaciones cuyo modelo constitutivo sea

expresión de conocimientos adquiridos, arraigados y transmitidos consuetudinariamente y
cuya factura se acomode, en su conjunto o parcialmente, a una clase, tipo o forma
arquitectónicos utilizados tradicionalmente por las comunidades o grupos humanos."

Bienes muebles: "Aquellos objetos que constituyen la manifestación o el producto de

actividades laborales, estéticas y lúdicas propias de cualquier grupo humano, arraigadas y
transmitidas consuetudinariamente."

Bienes intangibles: "Se considera que tienen valor etnográfico y gozarán de protección
administrativa aquellos conocimientos o actividades que procedan de modelos o técnicas
tradicionales utilizados por una determinada comunidad. Cuando se trate de conocimientos o
actividades que se hallen en previsible peligro de desaparecer, la Administración competente
adoptará las medidas oportunas conducentes al estudio y documentación científicos de estos
bienes."

4.4.1.5.Patrimonio documental y bibliográfico

"Lo constituyen los bienes reunidos en archivos y bibliotecas. Se entiende por documento, a
los efectos de la ley, toda expresión en lenguaje natural o convencional y cualquier otra
expresión gráfica, sonora o en imagen, recogidas en cualquier tipo de soporte material,
incluso los soportes informáticos."

4.4.1.6.Archivos, bibliotecas y museos

"Son archivos los conjuntos orgánicos de documentos, o la reunión de varios de ellos."

"Son bibliotecas las instituciones culturales donde se reúnen, conservan, seleccionan,

inventarían, catalogan, clasifican y difunden conjuntos o colecciones de libros, manuscritos y
otros materiales bibliográficos o reproducidos por cualquier medio para su lectura en sala
pública o mediante préstamo temporal, al servicio de la educación, la investigación, la
cultura y la información."

"Son museos las instituciones de carácter permanente que adquieren, conservan, investigan,
comunican y exhiben para fines de estudio, educación y contemplación conjuntos y
colecciones de valor histórico, artístico, científico y técnico o de cualquier otra naturaleza
cultural."
 4.4.2.El Registro de Bienes de Interés Cultural

4.4.2.1.Objeto
El Registro General de Bienes de Interés Cultural tiene por objeto la anotación e inscripción
de los datos que afecten a la identificación y localización de los bienes integrantes del
Patrimonio Histórico Español declarados de interés cultural. A dicho registro se notificará,
además, la incoación de todo expediente que se inicie para declarar un bien de interés cultural.
Dicha notificación causará una anotación preventiva hasta que recaiga resolución definitiva en
el expediente. Cada bien que se inscriba tendrá un código de identificación.

4.4.2.2.Datos inscribibles
En la relación con cada bien declarado de interés cultural se deberá hacer constar en el
registro los siguientes extremos:

• Los datos del extracto (Anexo I del reglamento).

• La descripción del bien con los suficientes datos que permitan su fácil y rápida
identificación.
• Fecha del Decreto declarando al bien de interés cultural.
• Fecha de la publicación de ese Decreto en el Boletín Oficial del Estado.
• Los propietarios están obligados a permitir y facilitar su inspección. En relación con
dicha obligación, figurará en el Registro el régimen de visitas acordado o las
condiciones del depósito sustitutorio de aquél.
• Las transmisiones, traslados y actos jurídicos que afecten al bien.
• Los anticipos reintegrables que la administración conceda para sufragar los gastos de
conservación, mantenimiento y custodia de bienes declarados de interés cultural.
• Las restauraciones que se comunicarán por el órgano que las autorice.

4.4.2.3.Privacidad
El registro es semipúblico. El artículo 22.1 del Real Decreto 111/1986, de 10 de enero, de
desarrollo parcial de la Ley 16/1985, de 25 de junio, del Patrimonio Histórico Español (en
adelante RDPHE86), dice al respecto: "será preciso el consentimiento expreso del titular
para la consulta pública de los datos contenidos en el Registro General sobre:

• La situación jurídica y el valor de los bienes inscritos.

 • Su ubicación, en el caso de bienes muebles, cuando por la Administración competente
se hubiera dispensado totalmente de la obligación de visita pública a que se refiere el
art. 13.2 de la Ley 16/1985."

Mientras que serán públicos los siguientes datos:

• Fecha del Decreto declarando al bien de interés cultural.

• Fecha del Boletín Oficial del Estado donde se publique el Decreto.
• El régimen de visitas.
• Los anticipos reintegrables concedidos por la Administración.
• Y las restauraciones.

4.4.3.El Inventario General

4.4.3.1.Objeto
"El Inventario General comprenderá los bienes muebles integrantes del Patrimonio
Histórico
Español, no declarados de interés cultural, pero que tengan una singular relevancia por su
notable valor histórico, artístico, científico, técnico o cultural. El precepto alude sólo a los
bienes muebles, por lo que los inmuebles no tienen acceso a este inventario. A él sólo
acceden aquellos bienes muebles del Patrimonio Histórico Español con ciertos valores
importantes, pero no lo suficiente para ser declarados bienes de interés cultural. Si son
declarados bienes de interés cultural acceden directamente al Registro de Bienes de Interés
Cultural; y si figurasen antes en El Inventario, causarán baja en éste al acceder al registro."

"Aquí ya es de detectar un diferente trato entre los bienes muebles y los inmuebles. Estos
últimos pueden ser declarados Bienes de Interés Cultural, pero no tienen acceso al
Inventario; este está reservado para los bienes muebles que, además, también pueden
adquirir la condición de Bien de Interés Cultural. No comprendemos la razón de que no
exista un Inventario de bienes inmuebles donde podrían acceder los que tuvieren valores
culturales pero no tan intensos como para ser declarados de interés cultural."

4.4.3.2.Datos inscribibles
"A cada bien que se inscriba se le asignará un código de identificación y en el Inventario
figurará:
 • Un extracto de expediente de inclusión.
• La fecha de inclusión del bien en el Inventario General.
• Las transmisiones por actos inter vivos y mortis causa.
• Los traslados de los bienes.
• Los anticipos reintegrables que conceda la Administración para la conservación,
mantenimiento y custodia, a los propietarios, titulares de derechos reales o simples
poseedores."

4.4.3.3.Privacidad
"El inventario es semipúblico, ya que no se permitirá la consulta pública, sin el
consentimiento expreso del titular, de los datos relativos a:

• Situación jurídica.
• Localización.
• Valoración económica."

4.5.Ley 4/1999, de 15 de marzo, de Patrimonio Histórico de Canarias

(B.O.C. nº 36, de 24/03/99)
Aunque en este proyecto se pretende generar un sistema genérico y flexible para la gestión del
patrimonio cultural independientemente de la localización u origen de los bienes, no hay que
olvidar que precisamente este patrimonio está constituido por lo que tienen de peculiar los
pueblos y les caracteriza. Por lo tanto los tipos de bienes tendrán características distintas para
distintas zonas, y habrán de ser recogidas por el sistema informático que se genere. Debido a
esto, durante el análisis de los requerimientos del sistema se tuvo en cuenta que fuera un
sistema flexible para dar cabida a todo tipo de bienes de distintas zonas. No obstante, aunque
el análisis y diseño se hicieron de una forma genérica, la implementación del sistema se
centró en el caso concreto de Canarias y más concretamente en Gran Canaria. Por ello
incluimos a continuación una breve reseña del contenido de la ley LPHC99 que sirve como
contexto del caso concreto de sistema que hemos implementado. Como en el caso anterior de
la LPHE85 el objetivo de la inclusión de este apartado es el de contextualizar el proyecto y a
la vez mostrar el origen de cualquier sistema de gestión que hubiera anterior al que
pretendemos desarrollar, centrándonos en las partes de la ley que claramente influenciarán la
aplicación informática que se ha diseñado. Como se verá más adelante en el análisis de
requerimientos del sistema y más tarde en las especificaciones, estos estarán directamente
influenciados por la ley.

4.5.1.Objeto y finalidad
La LPHC99 "tiene por objeto regular el régimen jurídico de los bienes, actividades y demás
manifestaciones culturales que integran el patrimonio histórico de Canarias."

"Es finalidad de la ley la protección, conservación, restauración, acrecentamiento,

investigación, difusión, fomento y transmisión en las mejores condiciones posibles a las
generaciones futuras del patrimonio histórico de Canarias, así como su disfrute por los
ciudadanos como objeto cultural y educativo y de su aprovechamiento como recurso
económico, en tanto tales usos armonicen con la referida finalidad."

4.5.2.Constitución del patrimonio histórico de Canarias

"El patrimonio histórico de Canarias está constituido por los bienes muebles e inmuebles que
tengan interés histórico, arquitectónico, artístico, arqueológico, etnográfico, paleontológico,
científico o técnico. También forman parte del patrimonio histórico canario los bienes
inmateriales de la cultura popular y tradicional y las particularidades lingüísticas del
español hablado en Canarias."

4.5.3.Clasificación

4.5.3.1.Bienes inmuebles

• Monumento: bienes que constituyen realizaciones arquitectónicas o de ingeniería, u

obras singulares de escultura siempre que sobresalgan por su valor arquitectónico,
técnico, histórico, artístico, científico o social.

• Conjunto histórico: agrupación de bienes inmuebles que forman una unidad de

asentamiento de carácter urbano o rural, continua o dispersa, o núcleo
individualizado de inmuebles condicionados por una estructura física representativa
de la evolución de una comunidad humana por ser testimonio de su cultura o
constituir un valor de uso y disfrute para la colectividad.

• Jardín Histórico: espacio delimitado, producto de la ordenación por el hombre de

elementos naturales, caracterizados por sus valores estéticos, sensoriales o botánicos
sobresalientes.
 • Sitio histórico: lugar o paraje natural vinculado a acontecimientos o recuerdos del
pasado de destacado valor histórico, etnológico, paleontológico o antropológico.
• Zona Arqueológica: lugar o paraje natural donde existen bienes muebles o inmuebles
representativos de antiguas culturas.

• Zona Paleontológica: lugar que contiene vestigios fosilizados o restos de interés

científico.

• Sitio Etnológico: lugar que contiene bienes, muebles o inmuebles, representativos de

los valores propios de la cultura tradicional o popular.

4.5.3.2.Bienes muebles

• Bienes Muebles Vinculados: conjunto de bienes declarados de interés cultural por su

vinculación a un inmueble declarado.

• Colección de Bienes Muebles: conjunto de bienes que sólo reúnen los valores
históricos para su declaración al ser considerados como una unidad.

• Bien Mueble: aquellos que de forma individual reúnen los valores históricos para su
declaración.

4.5.3.3.Conocimientos y actividades tradicionales

• De ámbito de Canarias: manifestaciones de la cultura popular, arraigadas o en

peligro de extinción, que contengan valores presentes en más de una isla canaria.

• De ámbito insular: manifestaciones de la cultura popular, arraigadas o en peligro de

extinción, que contengan valores presentes en una isla.

• De ámbito local: manifestaciones de la cultura popular, arraigadas o en peligro de

extinción, que contengan valores presentes en un ámbito inferior a una isla.

4.5.4.Competencias en la administración del patrimonio histórico

Entre otras competencias que detalla la Ley señalamos a continuación las que influyen
directamente con este proyecto.
 4.5.4.1.Competencias de la Administración pública de la Comunidad
Autónoma

• "Coordinar y fomentar la colaboración entre las distintas Administraciones

implicadas por razón de la materia o del territorio en la tutela y gestión del
patrimonio histórico canario."

• "Declarar los bienes de interés cultural y llevar el registro de tales bienes, así como el
Inventario de Bienes Muebles."

• "Coordinar la realización de inventarios, cartas, catálogos y demás instrumentos

necesarios para conseguir la unidad documental actualizada de los bienes históricos
de Canarias y su correspondiente informatización."

4.5.4.2.Competencias de los Cabildos Insulares

• "Emitir informe preceptivo y vinculante en la tramitación de los Planes Especiales de

Protección de los Conjuntos Históricos, Zonas Arqueológicas y Sitios Históricos.
Asimismo,”

• “Emitir informe preceptivo y vinculante en la tramitación de los Planes Especiales de

Protección de los Conjuntos Históricos, Zonas Arqueológicas y Sitios Históricos.
Asimismo,”

• “Emitir informe en la tramitación de los catálogos arquitectónicos municipales, y en

todos aquellos casos en que los instrumentos de planeamiento territorial y
urbanístico afecten a bienes de interés cultural o incluidos en cartas arqueológicas o
etnográficas."

• "Incoar y tramitar los expedientes de declaración de bienes de interés cultural,

elevándolos al Gobierno de Canarias para su aprobación, así como las
modificaciones de dichos expedientes."

4.5.4.3.Competencias de los Ayuntamientos

• "Formular y tramitar los Planes Especiales de Protección de los Conjuntos

Históricos, de conformidad con lo previsto en la legislación urbanística,
 estableciendo las medidas de fomento necesarias con objeto de conseguir su
preservación y revitalización."

• "Formular y tramitar, de conformidad con la normativa urbanística aplicable, el

catálogo arquitectónico municipal a fin de tutelar y conservar los edificios y
elementos de valor sitos en el término de la entidad."

4.5.4.4.Colaboración y coordinación

• "Las Administraciones Públicas canarias garantizarán el cumplimiento de las

funciones administrativas que les correspondan en materia de patrimonio histórico."

• "A estos efectos, en el marco de sus respectivas competencias, coordinarán sus

actuaciones, colaborando para el mejor desarrollo y ejecución de sus respectivas
funciones, de acuerdo con el sistema de competencias, régimen de actuación y
funcionamiento, y mediante los instrumentos de colaboración y de relación
interadministrativa previstos en la legislación sobre Régimen Jurídico de las
Administraciones Públicas de Canarias."

• "El Gobierno de Canarias velará para que el ejercicio de las competencias

transferidas o delegadas desde la Administración de la Comunidad Autónoma a los
Cabildos Insulares, y en su caso a los Ayuntamientos, en materia de patrimonio
histórico, se rewww.dbhost.net con medios suficientes para garantizar su
preservación."

4.5.5.Protección del Patrimonio Histórico de Canarias

4.5.5.1.Disposición general
Lo bienes integrantes del patrimonio histórico canario se incluyen en alguno de los siguientes
instrumentos:

• Registro de Bienes de Interés Cultural.

• Inventario de Bienes Muebles.
• Catálogos arquitectónicos municipales.
• Cartas arqueológicas municipales.
• Cartas etnográficas municipales.
• Cartas paleontológicas municipales.
 4.5.5.2.Centro de Documentación del Patrimonio Histórico
“Los datos contenidos en los instrumentos citados en el artículo anterior (hace referencia a
la disposición general), así como los resultantes de los inventarios de fondos de los museos
de Canarias y otros que asimismo se estime se integrarán en un Centro de Documentación
del patrimonio histórico, dependiente de la Administración Pública de la Comunidad
Autónoma de Canarias, donde se recopilarán y mantendrán actualizados en soportes
informáticos.”

“La información disponible en dicho Centro de Documentación se facilitará gratuitamente a

las Administraciones Públicas de Canarias con competencia en materia patrimonial y
territorial y a los departamentos universitarios para el mejor cumplimiento de sus fines
docentes e investigadores. Dicha información también se facilitará a los particulares que
acrediten un interés legítimo.”

4.5.6.Registro Canario de Bienes de Interés Cultural

Los bienes declarados de interés cultural se inscribirán en el Registro Canario de bienes de
interés Cultural mediante decreto del Gobierno de Canarias, a propuesta de la Administración
actuante, y previo informe favorable del Consejo Canario del Patrimonio Histórico.

4.5.7.Inventario de Bienes Muebles

“Los objetos muebles que ostenten especiales valores artísticos, etnográficos o históricos,
sean de titularidad pública o privada, deberán ser incluidos, previo expediente formulado al
efecto, en el Inventario de Bienes Muebles.”
 PARTE II

CONTEXTO TECNOLÓGICO
5. Ingeniería del software
El término Ingeniería se define en el diccionario de la Real Academia Española (www.rae.es)
como "1. f. Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología.", y
la aplicación de la ingeniería al software es lo que conocemos como ingeniería del software.

Según la definición obtenida de los estándares de IEEE: "Ingeniería del Software es la

aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo,
operación y mantenimiento del software."[PRESS02].

La ingeniería del software comprende tres elementos: los métodos, las herramientas y un
proceso.

Lo métodos son las indicaciones de como construir técnicamente el software. Abarcan una
gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas,
pruebas y mantenimiento. "Los métodos de la ingeniería del software dependen de un
conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen
actividades de modelado y otras técnicas descriptivas."

Las herramientas son el soporte técnico (automático o semiautomático) para el desarrollo del
software. Existen herramientas explícitamente creadas para un entorno de ingeniería del
software. Son las llamadas herramientas CASE (Computer Aided Software Engineering,
ingeniería del software asistida por ordenador).

El proceso es un marco de trabajo de las tareas que se requieren para construir software de
alta calidad. "Define una secuencia en la que se aplican los métodos, las entregas que se
requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios, y las
directrices que ayudan a los gestores a evaluar el progreso." Para el proceso de este proyecto
se optó por el modelo incremental de proceso de software. El modelo incremental está basado
en una suma del modelo secuencial o en cascada más el modelo de construcción de
prototipos.

5.1.Modelo lineal secuencial

En el modelo lineal secuencial o también llamado modelo en cascada se plantea un diseño en
línea recta. Este modelo asume que se conocen o se obtienen todos los requisitos del sistema
al inicio del proceso y establece una serie de pasos que llevan a la consecución del producto.
Estos pasos son: análisis, diseño, generación del código, pruebas y mantenimiento.

Análisis Diseño Código Pruebas Mantenimiento

El modelo lineal secuencial

5.1.1.Análisis de los requisitos de usuario y del software

Durante esta fase se pone énfasis en investigar el problema que queremos resolver no en
aportar una solución. Al final de esta fase obtendremos uno o varios documentos de
especificaciones en los que quedará patente lo que esperamos del sistema.

Los requisitos se pueden clasificar de acuerdo con el modelo FURPS+ en los siguientes tipos:

• Funcional (Functional)
• Facilidad de uso (Usability)
• Fiabilidad (Reliability)
• Rendimiento (Performance)
• Soporte (Supportability)
• Implementación
• Interfaz
• Operaciones
• Empaquetamiento
• Legales

5.1.2.Diseño
El proceso de diseño se centra en crear una solución conceptual que satisfaga los requisitos.
Se generan un modelo conceptual del dominio del problema y un modelo de clases.

5.1.3.Generación de código
El diseño se traduce en una implementación concreta de la solución directamente operacional
en una máquina.
 5.1.4.Pruebas
Cuando se finaliza el desarrollo del código se procede a la comprobación de su
funcionamiento.

5.1.5.Mantenimiento
Una vez terminado el software, este permanece en revisión de posibles errores, o es posible
que sean necesarias adaptaciones a nuevas circunstancias, que sean diferentes a las que había
al finalizar la implantación del producto.

5.2.Modelo de construcción de prototipos

Existen situaciones en las que el modelo secuencial posee algunos inconvenientes. Por
ejemplo, es bastante común que el cliente no identifique de manera detallada los requisitos del
sistema de entrada, o no se conozca con seguridad la eficacia de un algoritmo hasta que no se
implementa. En tales circunstancias se hace conveniente la construcción de un modelo que
reproduzca el software que queremos desarrollar. La construcción de un prototipo nos permite
ir refinando paulatinamente con el cliente los requisitos de la aplicación.

Escuchar al cliente Diseño rápido

El cliente prueba Construir/revisar

la maqueta el prototipo

Modelo de construcción de prototipos

5.3.El modelo incremental

El modelo incremental combina elementos del modelo lineal secuencial (aplicados
repetidamente) con la filosofía interactiva de construcción de prototipos. Una de las ventajas
del modelo incremental es que entrega el software en partes pequeñas llamadas incrementos.
Cada incremento se construye a partir del anterior.
 Incremento 1: Inventarios Insulares

Análisis Diseño Código Pruebas Mantenimiento

Incremento 2

Análisis Diseño Código Pruebas Mantenimiento

Incremento 3

Análisis Diseño Código Pruebas Mantenimiento

Tiempo

Se ha elegido este modelo de desarrollo para el proyecto porque se adapta a las características
del mismo por los siguientes motivos:

• Aunque se documentarán ampliamente todos los requisititos del sistema, se trata de un

producto bastante complejo por lo que es aconsejable un desarrollo escalonado.

• El proyecto pretende abarcar una primera fase o modulo del sistema global que
resultaría de una informatización de todos los procesos, actividades y entidades que
intervienen en la gestión del patrimonio histórico, según la Ley y la situación
establecida en la práctica. En concreto se centrará en la creación de una aplicación
para la gestión de los inventarios insulares que se describen en el apartado de Sistema
de gestión del Patrimonio Cultural.

5.4.Ingeniería web
Internet comenzó siendo un mero soporte de intercambio de información. A través de la red se
compartían documentos, imágenes, etc. Poco a poco fue aumentando el número de servicios
que ofrecía y el número de actividades y procesos que se desarrollaban en su ámbito.
Podríamos decir que en cuanto a las entidades corporativas ha habido un proceso incremental
de "virtualización" de las empresas. Se ha pasado de una situación en la cual Internet
constituía un almacén donde volcar la información a ser una herramienta de recolección de
datos, y finalmente a constituirse comoElelmodelo
soporteincremental
total de los sistemas de información de las
empresas.
Si vemos una empresa como un sistema de información podríamos decir que se trata de un
sistema que recibe una información, la procesa y genera una información como resultado.

Empresa/Sistema de información

Entrada de Procesado de Salida de

información información información

Proceso de integración de la Web en las aplicaciones

corporativas

Una aplicación es un programa que implementa el sistema de información de una empresa. En

un primer momento (1) las empresas tenían un programa local que recogía la información, la
procesaba y generaba una salida que era posteriormente compartida mediante la Web. Más
tarde se utilizó la propia Web como medio de recogida de la información (2), y finalmente se
construyeron aplicaciones diseñadas para la web, con lo que quedaba totalmente integrada la
aplicación en Internet. Este tipo de aplicaciones son conocidas como aplicaciones web o
WebApps (del inglés Web Applications). Para este nuevo tipo de aplicaciones es necesario
replantear los conceptos de la ingeniería del software para adaptarlos al nuevo contexto de
aplicación. Estos conceptos son en su mayoría reciclables, teniendo que ser revisados en base
a las nuevas características de estas aplicaciones como son: su intensidad en red, su evolución
continua, su inmediatez (cortos períodos de desarrollo), su nivel de seguridad y su estética,
entre otros.
Por ejemplo, en el caso de los requisitos de calidad se ha propuesto un replanteamiento de los
mismos para las aplicaciones web por Olsina L. [PRESS02].
 PARTE III

APLICACIÓN WEB
6. Sistema de Gestión del Patrimonio Cultural
Este proyecto se centra en la creación de una herramienta informática para la gestión de los
inventarios insulares, concretamente para los bienes inmuebles de carácter etnográfico,
arqueológico y arquitectónico.

Es conveniente delimitar con exactitud el área de actuación de la aplicación informática que

se ha creado, es decir, definir con precisión en que parte de la realidad se enmarca este
sistema.

6.1.Contexto jurídico-administrativo
En este apartado se resumen los distintos instrumentos administrativos que contemplan las
leyes de patrimonio. A partir de este listado limitaremos el subconjunto de instrumentos que
se implementaron en este proyecto.

De ámbito nacional
Registro de Bienes de Interés Cultural Bienes de Interés Cultural
El Inventario General Bienes muebles con singular relevancia no declarados de
interés cultural
De ámbito autonómico (Canarias)
Registro Canario de Bienes Muebles Bienes de Interés Cultural
Inventario de Bienes Muebles Bienes muebles que ostenten especiales valores no
declarados de interés cultural
De ámbito insular
Inventarios insulares Bienes inmuebles Etnográficos
Arqueológicos
Arquitectónicos
(Este proyecto resuelve el problema
de la gestión de estos tres
inventarios)
Bienes muebles ...
Conocimientos y ...
actividades
tradicionales
De ámbito municipal
Catálogos arquitectónicos municipales
Cartas arqueológicas municipales
Cartas etnográficas municipales
Cartas paleontológicas municipales

Lo que se ha denominado Inventarios Insulares no se corresponde directamente con ningún

instrumento concreto mencionado por la ley. Se trata de herramientas que podrían enmarcarse
en la LPHC99 dentro del artículo 6.1 párrafo 'd' que hace mención a que "la Administración
Pública de La Comunidad Autónoma le corresponde la realización de inventarios, cartas,
catálogos y demás instrumentos necesarios para conseguir la unidad documental actualizada
de los bienes históricos de Canarias y su correspondiente informatización". En la práctica se
da el caso de que entidades públicas como los cabildos pueden realizar un inventario amplio y
exhaustivo de algún tipo de bien en el que se recojan todos los que tengan algún interés, para
posteriormente ser introducidos en alguno de los instrumentos estipulados ex profeso por la
Ley. Estos son el Registro, el Inventario y las cartas y catálogos. Es el caso de, por ejemplo, la
carta etnográfica de Gran Canaria realizada por la FEDAC (Fundación para la Etnografía y el
Desarrollo de la Artesanía Canaria) un organismo autónomo del Cabildo de Gran Canaria que
ha realizado y mantiene un inventario extenso de los inmuebles de interés etnográfico de Gran
Canaria.

6.2.Contexto tecnológico
Como se especifica en el título del proyecto, el sistema que se ha generado será implantado en
Internet en confrontación con la opción de generar una aplicación que se ejecute en modo
local. Es evidente el incremento en los últimos años del número de aplicaciones web pensadas
para funcionar en Internet, y son indudables sus ventajas en cuanto a accesibilidad universal.

Debido al carácter distribuido del sistema y a sus perspectivas de escalabilidad se optó por
diseñar un sistema web. Esta es la razón principal, no obstante se justificará esta opción en
otros apartados de forma más sistemática y técnica en base a los requerimientos, costes,
funcionalidades, etc.

En la actualidad el sistema de gestión de los inventarios esta soportado por bases de datos en
Access y en el caso del Inventario Insular de Inmuebles Etnográficos ha sido volcado a
Internet. Se estudiará con más detalles el sistema actual en el apartado de antecedentes.
7. Antecedentes. Análisis del sistema actual
El sistema actual que se ha analizado es el que mantiene el Cabildo de Gran Canaria en la
actualidad. Existen tres bases de datos locales implementadas en Microsoft Access, una para
cada tipo de patrimonio: etnográfico, arqueológico y arquitectónico.

7.1.Inventario Insular Etnográfico

El inventario de bienes inmuebles de Gran Canaria depende de un organismo autónomo del
Cabildo de Gran Canaria que es la Fedac (Fundación para la Etnografía y el Desarrollo de la
Artesanía Canaria). En la sede de la Fedac existe a disposición de los ciudadanos un punto de
información en donde se puede consultar la Carta Etnográfica de Gran Canaria. Es posible
acceder a esta información a través de la Web en la dirección www.cartaetnograficagc.org.

En este sistema intervienen los siguientes actores:

• Cualquier consultor puede consultar los datos de un bien etnográfico ya sea en el

punto de información o vía web.

• Existe un técnico responsable del mantenimiento de los datos de la carta. Este técnico
editor controla las fichas que se incluyen, las modificaciones, etc.

• Existe un técnico administrador encargado de modificaciones de la estructura de los

datos y de actualizar la información de la web con la de la base de datos local. Este
proceso se sincronización consiste básicamente en actualizar el fichero de la base de
datos que usa la web con la última versión local del mismo.

Se pueden realizar varias acciones en la base de datos local que está disponible en el punto de
información de la sede de la Fedac. Algunas de estas tareas son:

• Consulta a la tabla principal que contiene un listado de todos los bienes etnográficos.
• Consultas por campos.
• Consultas por tipologías y municipios.
• Consultas por zonas.
• Localización de las fichas en el mapa.
• Copias de seguridad.
 • Impresión de informes.
• Etc.

En cuanto al acceso vía web podemos:

• Utilizar un buscador que nos permite buscar por municipio, actividad y palabras clave.
• Acceder a una ficha directamente mediante su código.
• Ver un listado de los bienes consultados que incluye el número de la ficha, una imagen
reducida del bien, el nombre, toponimia, localidad y municipio.
• Ver los detalles de una ficha. Se accede a través del listado o mediante el acceso
directo a una ficha soportado por el buscador.

En lo que concierne a este proyecto nos centraremos en un subconjunto de las acciones. Se

incluirán algunas acciones de la base de datos local (como el insertar nuevas fichas y
editarlas) y casi la mayoría de las opciones que ofrece la web. Para más detalle sobre las
actividades que ofrecerá el software que se generó para este proyecto, consulte el apartado de
objetivos, o los documentos de especificaciones.

Para el análisis de este sistema se tuvo acceso al modelo de datos empleado por la base de
datos de la aplicación. Este modelo de datos se encuentra en uno de los anexos de la memoria.

7.2.Inventario Insular Arqueológico y Arquitectónico

Los inventarios insulares de patrimonio arqueológico y arquitectónico se encuentran en bases
de datos de Microsoft Access del Servicio de Patrimonio Histórico dependiente de la
Consejería de Cultura y Deportes del Cabildo de Gran Canaria.

Estas bases de datos son accesibles solo a personal administrativo. En este caso los principales
actores que intervienen son los siguientes:

• Los usuarios consultores que son también personal técnico y administrativo.

• Un usuario editor por cada tipo de bien que se encarga del mantenimiento de los datos
de la base de datos.
 • Un usuario administrador que puede modificar la estructura de las tablas de la base
de datos.

En cuanto a las acciones que se pueden realizar son, entre otras:

• Ver un listado completo de todos los bienes.

• Realizar una consulta por campos.
• Realizar consultas por tipologías y municipios.
• Ver el contenido de la ficha de una bien.
• Insertar nuevos bienes, modificar y borrar los existentes.
• Imprimir informes de fichas o listados.
• Etc.

Para este proyecto solo se contemplará un subconjunto de acciones de las implementadas por
el sistema actual especificado en los objetivos y documentos de especificaciones. Se ha
incluido un anexo donde se encuentra el modelo detallado de datos usado por estas
aplicaciones.
8. Objetivos
En esta memoria del proyecto se hace referencia a tres sistemas de información: el sistema
actual, el nuevo sistema global y la aplicación web desarrollada en este proyecto.

Por un lado tenemos el sistema actual, que se usa para la gestión del patrimonio y que se
describió en apartados anteriores (antecedentes).

Por otro lado el nuevo sistema global sería el sistema que obtendríamos de un análisis de
todos los requisitos del sistema actual más otros requisitos derivados del análisis completo de
la gestión del patrimonio en general.

Por último está el sistema de gestión de inventarios insulares que es la parte del sistema
global en que se centra el proyecto, y que constituye el problema que pretendemos resolver.

En la siguiente tabla se muestra claramente cual es el objetivo del sistema que se creó en este
proyecto.
 Sistema Objetivos

Base de datos en Microsoft Access para la gestión del inventario

insular de bienes inmuebles etnográficos
Sistema actual Base de datos en Microsoft Access para la gestión del inventario
insular de bienes inmuebles arqueológicos
Base de datos en Microsoft Access para la gestión del inventario
insular de bienes arquitectónicos

Sistema que cumple todos los requisitos de usuario y software para

una gestión completa del patrimonio cultural a nivel nacional,
Nuevo sistema autonómico e insular, teniendo en cuenta la Ley y los sistemas
global actuales que estén en funcionamiento.
Incluiría gestión de cartas y catálogos municipales, así como de
registros e inventarios regionales y nacionales.

P.F.C. Gestión de los inventarios insulares para los bienes de tipo

Sistema de Gestión etnográfico, arqueológico y arquitectónico.
del Patrimonio El proyecto debe ser visto como el incremento 1, en el proceso
Cultural. incremental de desarrollo (ingeniería del software) del nuevo sistema
global.

Por lo tanto el objetivo principal del proyecto es diseñar e implementar una aplicación web
para la gestión de los inventarios de bienes inmuebles de carácter etnográfico, arqueológico y
arquitectónico que permita:

• Contener y gestionar los inventarios insulares de las 7 islas del archipiélago canario.
• Consultar los inventarios por parte de cualquier usuario desde cualquier punto de
acceso a la web.
• Gestionar los inventarios (altas, bajas y modificaciones) desde cualquier punto de
acceso a la web.
9. Planificación
Una vez definidos los objetivos del proyecto es necesario establecer un plan de desarrollo
para minimizar el impacto de posibles imprevistos y garantizar la correcta ejecución del
mismo. El desarrollo del sistema estará enmarcado dentro de un proceso de ingeniería del
software. El modelo elegido ha sido una versión adaptada a este proyecto del modelo
incremental de Larman [LAR99].

Planificación Construcción Aplicación

Incremento1 Incremento2 Incremento3

Análisis Diseño Implementación Pruebas

Proceso de desarrollo utilizado

9.1.Planificación temporal
Cada unas de la tareas a llevar a cabo durante el desarrollo requieren de una estimación
inicial temporal que nos ayudará en la organización y control del proceso. Estas estimaciones
nos servirán como medida de comprobación del estado de desarrollo del proyecto. Los
tiempos estimados fueron los siguientes:

• Formación en programación web e investigación: 60-80 horas

• Análisis y diseño del sistema: 25 horas
• Implementación y pruebas: 150-200 horas
• Documentación del trabajo: 50 horas
10.Investigación
La primera fase previa al desarrollo de cualquier proyecto consiste en investigar el problema
que queremos resolver. Es necesario familiarizarse con las entidades y procesos que se
desarrollan en el ámbito del problema al que pretendemos dar solución. En este proyecto la
investigación previa se centró básicamente en dos aspectos: por un lado la investigación del
dominio del problema, y por otro lado la investigación en cuanto al aspecto técnico de las
soluciones previas y las posibles soluciones que podrían plantearse.

Indudablemente esta fase de investigación se trata de un acercamiento previo al problema que

se nos plantea. En la fase de análisis se llevará a cabo un estudio más pormenorizado y
metodológico del sistema actual, así como después en la fase de diseño e implementación se
realizará un estudio amplio de la tecnología disponible para realizar el producto.

10.1.Investigación del dominio del problema

Una de las primeras tareas fue la indagación sobre el sistema actual de forma general, no solo
desde el punto de vista técnico informático sino en cuanto a sus entidades y relaciones reales.

En el proceso de investigación se acudió a las instituciones que actualmente gestionan los

inventarios insulares: la Fedac y el Servicio de Patrimonio Histórico de la Consejería de
Cultura y Deportes del Cabildo de Gran Canaria. Se recabó información acerca del
funcionamiento de los inventarios: personal involucrado, procesos en la gestión de los bienes,
e incluso se obtuvieron los modelos de datos de los sistemas informáticos que están
actualmente en uso. Además, se recurrió a la Ley de Patrimonio Histórico Español de 1985 y
la de Patrimonio Histórico de Canarias de 1999 para completar esta información, y sobretodo
para enmarcar el proyecto en un contexto general, y poder situarlo dentro del sistema global.

También se amplió está información recogida con bibliografía sobre la gestión del patrimonio
cultural e información obtenida a través de Internet. En el apartado de antecedentes se puede
consultar un resumen de la información obtenida después de esta fase de investigación.

10.2.Investigación técnica
Al inicio del proyecto hubo una fase de investigación técnica más centralizada en los aspectos
informáticos del sistema actual y el sistema que se pretendía construir. Para esta labor se
acudió a los organismos que se encargan actualmente de la gestión de los inventarios (Fedac y
Servicio de Patrimonio Histórico de la Consejería de Cultura y Deportes). Se hicieron
entrevistas a los técnicos encargados de la gestión y se obtuvieron datos técnicos del modelo
actual del sistema, entre ellos el modelo actual de datos de las bases de datos que se adjunta
en el anexo I.

No solo se investigó el sistema actual, sino que fue necesario un periodo de adquisición de
conocimientos acerca de la programación de aplicaciones web, ya que para el plan de estudios
en el que se encuadra este proyecto no existía ninguna asignatura específica de esta materia.

Parte de la información recolectada durante esta fase se encuentra en el apartado de

antecedentes y en otros apartados.
11.Análisis

11.1.Definición del problema

El problema que se pretende resolver en este proyecto es la gestión de los Inventarios
Insulares de bienes inmuebles de carácter etnográfico, arqueológico y arquitectónico.
Existe un inventario por cada tipo de bien e isla. Los inventarios pueden ser consultados por
cualquier persona en general y actualizados solo por personal administrativo.

11.2.Análisis de requisitos de usuario

Los objetivos para esta fase del desarrollo son:

• Identificar los conceptos que existen en el ámbito del problema que queremos
solucionar.
• Identificar relaciones entre los conceptos.
• Identificar actividades y procesos que realizan los actores.

Como resultado de esta fase se obtiene un modelo del dominio o modelo conceptual.

11.3.Documento de requisitos de usuario

En el documento de requisitos de usuario se especifican las necesidades del usuario que debe
cubrir el software que vamos a desarrollar, desde el punto de vista funcional y sin entrar en
detalles técnicos de cómo se han de solucionar dichas necesidades. En nuestro caso la
aplicación que se necesitaba debía cumplir los siguientes requisitos:

• El usuario consultor puede consultar los inventarios desde cualquier punto de Internet.
• El acceso a los inventarios debe ser sencillo e intuitivo.
• Será necesario que el usuario pueda cambiar de inventario tanto de tipo de bien como
la zona a la que pertenece, de una manera fácil y rápida.
• Los usuarios encargados de la gestión de los datos podrán gestionar los inventarios
desde cualquier punto de Internet.
• Es imprescindible que haya una seguridad y garantía de que los datos no son
modificados por usuarios que no sean los encargados de mantener los datos de los
inventarios.
 • Es imprescindible que el usuario pueda realizar consultas a los inventarios que le
permitan encontrar la información precisa que busca acerca de los bienes.
• Un requisito menos importante pero útil sería que los usuarios del sistema puedan
personalizar su relación con este, definiendo la forma en la que el sistema se les
presenta.
• Un requisito adicional pero importante es que la interacción con el sistema sea
cómoda, sencilla, intuitiva y agradable.

11.4.Análisis de requisitos de software

Los objetivos para esta fase son:

• Identificar los objetos que van a estar presentes en el software que se va a desarrollar.
• Identificar las operaciones disponibles sobre estos objetos.

Como resultado se obtendrá un modelo del software.

11.5.Documento de requisitos de software

A partir de la lista de requisitos de usuario se elabora una lista con las capacidades que tiene
que cumplir el software que vamos a desarrollar. Estas capacidades son las siguientes:

• El software que desarrollemos tiene que estar implementado en una tecnología que
permita implantarlo en Internet.
• Es necesario que se pueda instalar en distintas plataformas de servidores de Internet,
Windows y Linux como mínimo.
• Tiene que permitir acceder a distintas bases de datos de distintas zonas de forma
transparente al usuario.
• Debe garantizar la no manipulación de los inventarios por personas no autorizadas. Es
decir tiene que incorporar un sistema de validación de los usuarios.
12.Diseño
Es en esta fase en la se pasa de estudiar el problema a proponer una solución. La solución
propuesta constará de un diseño documentado de arquitectura de la aplicación, en la que
aparecerán las relaciones del sistema con el exterior y su estructura interna: su
descomposición en módulos y la relación entre estos y las clases que los componen. En
definitiva, se obtendrá un modelo detallado del software, de las clases que lo integran, su
comportamiento y la relación entre estas.

Uno de los principales condicionantes en el trabajo de ingeniería para el desarrollo del

software es el coste, tanto temporal como económico. Tan importante como el que se genere
un software de calidad eficaz y eficiente es que se genere a un coste mínimo y en la menor
cantidad de tiempo posible. Uno de los errores más comunes en el proceso de desarrollo de
una nueva aplicación consiste en reinventar la rueda. Es decir, a partir de un análisis
exhaustivo del problema que queremos resolver plantear una solución completamente
autónoma, creada desde cero, y sin tener en cuenta posibles soluciones aportadas
anteriormente al mismo problema. Este tipo de actitud puede llevar incluso al fracaso de un
proyecto debido a los importantes costos de ejecución del mismo. Por lo tanto, es totalmente
indispensable y conveniente realizar un estudio preliminar de las soluciones anteriores a
nuestro problema u otros problemas similares. De esta forma es posible tener identificados
desde el inicio del diseño puntos críticos del sistema, o incluso hacer uso total o parcial de
algunas de las soluciones ya planteadas. Hoy en día, gran parte del trabajo de un ingeniero de
software consiste más en articular las piezas de que dispone que de reinventar nuevas piezas,
sobretodo en el ámbito de las aplicaciones de gestión.

12.1.Estudio preliminar
En base a los requerimientos del sistema identificados en la fase de análisis se llega a la
conclusión evidente de que el software que necesitamos desarrollar es una aplicación web.
Una vez sepamos que tipo de aplicación vamos a generar es necesario un estudio preliminar
de las características de este tipo de aplicaciones.

Hemos dividido este estudio preliminar en varios apartados que van desde los aspectos más
genéricos de la programación de aplicaciones web hasta los más concretos.
 12.1.1.Tecnologías web
Haremos un breve repaso de los lenguajes y herramientas más difundidas para la
programación de aplicaciones web.

• HTML: Acrónimo Hyper Text Markup Language (lenguaje de marcación de

hipertexto). Es un lenguaje de marcas diseñado para estructurar textos. La última
especificación disponible del lenguaje es la 4.0. El HTML es hijo del SGML (Standard
Generalized Markup Language) que es un lenguaje de marcación generalizado. Se
trata de un sistema para la organización y etiquetado de documentos que estandarizó la
Organización Internacional de Estándares (ISO) en 1986.

• XML: Es el acrónimo del inglés eXtensible Markup Language (lenguaje de marcado

ampliable o extensible) desarrollado por el World Wide Web Consortium (W3C). Es
una versión simple de SGML cuyo objetivo principal fue el desarrollar un sucesor de
HTML que separará contenido de estructura, y que permitiera definir varios
vocabularios. En cuanto a esta función de sucesor del HTML se está desarrollando
mediante la especificación XHTML. Han surgido otros usos como estándar para el
intercambio de datos entre aplicaciones.

• XHTML: Acrónimo inglés de eXtensible Hiper Text Markup Language (lenguaje

extensible de marcado de hipertexto). Es la versión XML del HTML pensado para
sustituir a este último. Su objetivo es avanzar en lograr una web más semántica donde
la información y la forma de representarla estén claramente diferenciadas.

• CSS: Las hojas de estilo en cascada (Cascade Style Sheets) son un lenguaje formal
para definir la presentación de un documento estructurado en HTML, XML y
XHTML.

• JavaScript: Es un lenguaje interpretado orientado a las páginas web. Se ejecuta en el

navegador del cliente. Fue inventado por Breadan Eich en la empresa Netscape
Comunications que fabricó los primeros navegadores de Internet comerciales. En 1997
fue adoptado como un estándar por la ECMA (European Computer Manufacturers
Association) con el nombre de ECMAScript.
• JScript: Es la implementación de ECMAScript de Microsoft muy similar a JavaScript
pero frecuentemente incompatible.

• DOM: El Document Object Model (en inglés, Modelo de Objetos de Documento) es

un modelo para representar los objetos con sus atributos y métodos que componen los
documentos HTML o XML. Es un API independiente del lenguaje para acceder,
añadir y cambiar dinámicamente contenido estructurado en páginas web. Actualmente
navegadores como el Internet Explorer de Microsoft han añadido extensiones a este
estándar, dificultando de esta manera la compatibilidad entre navegadores.

• DHTML: Del inglés Dinamic HTML (HTML dinámico) designa el conjunto de

técnicas que permiten crear sitios web interactivos, combinado HTML estático, con
lenguaje de script del lado del cliente (como JavaScript) y hojas de estilo (CSS).

• CGI: Common Gateway Interface (en inglés, Pasarela de Interfaz Común) es un

estándar que permite a un cliente (navegador web) solicitar datos de un programa
ejecutado en un servidor web. CGI fue una de las primeras maneras prácticas de
generar contenido dinámico para una página web. Un cliente solicita la ejecución de
un programa en el servidor, este programa se ejecuta y la salida es reenviada al cliente
en forma de documento HTML. Uno de los lenguajes más utilizados al principio fue el
Perl debido a que uno de sus puntos fuertes era el procesamiento de textos y archivos.

• PHP: Es el acrónimo recursivo de “PHP: Hipertext Preprocesor” (PHP: Preprocesador

de Hipertexto) creado inicialmente con el nombre PHP Tools o Personal Home Page
Tools. Es un lenguaje interpretado concebido por Rasmus Lerdorf en 1994. Se utiliza
para la programación de páginas web, para dotarlas de contenido dinámico. El código
PHP puede ser incrustado en un documento HTML. El servidor web ejecutará dicho
código antes de devolver la respuesta al cliente, de esta manera podemos modificar
dinámicamente el contenido de la página.

• ASP: Acrónimo de Active Server Pages. En un lenguaje derivado del Visual Basic
creado por Microsoft para la ejecución de código en el lado del servidor web. Forma
parte del servidor web de Microsoft (Internet Information Server). Se podría
considerar la versión equivalente del PHP de Microsoft.
 • ColdFusion: Se trata de un servidor de aplicaciones web y un lenguaje de
programación del mismo nombre desarrollado por la empresa Macromedia. Es un
lenguaje basado en tags y del lado del servidor al estilo de PHP o ASP.

• JSP: Java Server Page es la tecnología para desarrollar páginas web dinámicas en el
lado del servidor de Sun Microsystems. Esta tecnología permite empotrar código Java
en páginas web. Es el equivalente de PHP, ASP o ColdFusion pero con Java. Las
ventajas de esta tecnología son su independencia con respecto al sistema y su
integración con otras clases de Java.

• Applets y Servlets: Son dos APIs que proporciona la plataforma de desarrollo J2EE
(Java 2 Enterprise Edition) de Sun para la programación de aplicaciones web en el
lado del cliente y en el lado del servidor respectivamente. Son clases de software que
encapsulan un conjunto de acciones que se pueden llevar a cabo del lado del
navegador web (applets) o del lado del servidor web (servlets).

• Active X: Es un estándar de Microsoft para la construcción de componentes que

pueden ser empleados en distintos entornos entre ellos una página web. El
inconveniente de los controles Active X frente a los applets de Java es su dependencia
del sistema operativo. Los Active X solo se ejecutan sobre plataformas Windows.

• Flash: Macromedia Flash es un entorno para la edición multimedia. Mediante este

entorno se pueden generar componentes que se pueden integrar en una página web.

Para la realización de este proyecto se optó por el uso de PHP como lenguaje de
programación. Esta elección estuvo basada en criterios objetivos como pueden ser: su extensa
difusión en Internet, por su rapidez frente a otros lenguajes, por su portabilidad y
compatibilidad entre distintos sistemas, por la disponibilidad de servidores web que lo
soportan, por la gran cantidad de librerías y aplicaciones desarrolladas en PHP, por su profusa
documentación, extensa red de ayuda en web (foros y listas de correo), por la facilidad de
mantenimiento del código y por su coste cero.

12.1.2.Framework para aplicaciones web

Un framework, que literalmente se traduce del inglés como marco de trabajo, es un conjunto
de clases que proporcionan un soporte o estructura base sobre la que adaptar el desarrollo de
otras aplicaciones. Se trata de un esqueleto de aplicación que abstrae un conjunto de
herramientas y servicios que son comunes a multitud de aplicaciones. Trasladado al caso de
las aplicaciones web, un framework nos proporciona un conjunto de clases que resuelven
tareas comunes a todas las aplicaciones web, como por ejemplo, la gestión de peticiones y
respuestas entre el cliente y el servidor web. Los frameworks nos permiten centrar el esfuerzo
del diseño en resolver el problema del dominio que se nos ha planteado, sin tener que volver a
diseñar aspectos de las aplicaciones web que son comunes a todas, y que ya han sido
resueltos. Por supuesto la utilización de uno de estos framework se justificará en base a su
adaptabilidad a este proyecto.

Los frameworks se diferencian de las librerías en que estas últimas son un conjunto de clases
a las que recurre nuestra aplicación, mientras que en el caso de los framework, las clases
formarán parte del corazón del diseño de la aplicación.

Clases propias Clases propias

Framework Librerías

Uso de un framework Uso de librerías

Diferencias entre el uso de un framework y las librerías

12.1.3.Arquitectura MVC
Uno de los modelos más usados en el diseño de arquitecturas de software para aplicaciones
web es la arquitectura MVC.

La arquitectura MVC (Model View Controller, en castellano Modelo Vista Controlador) es un

patrón de diseño de software que consiste en dividir el software en tres componentes
principales: el modelo de datos de la aplicación, la interfaz con el usuario y la lógica de
control.
 CONTROLADOR VISTA

CONTROLADOR VISTA
MODELO

CONTROLADOR VISTA

Arquitectura MVC

• El modelo de datos representa la parte de software que se encarga de modelar los

conceptos del dominio. Se supone que es la parte más estable y que menos sufre
cambios.

• La interfaz de usuario o vista la constituyen aquellos componentes encaminados a

mostrar una representación concreta del modelo.

• El controlador está compuesto por la parte del software que se encarga de relacionar
las entradas externas al sistema con las acciones que es necesario ejecutar sobre el
modelo.

Este patrón fue descrito por primera vez en 1979 por Trygve Reenskaug en el diseño del
lenguaje de programación Smalltalk.

Un ejemplo de implementación de un sistema mediante el patrón MVC, podría ser el de un

sistema para la creación de paisajes en 3D a partir de mapas de curvas de nivel. En esencia los
pasos podrían ser los siguientes:

Introducir mapa Animación 3d

Modelo
Editar vértices matemático del Perspectiva estática

paisaje
Editar parámetros Malla de polígonos

Arquitectura MVC para un sistema de generación de paisajes en 3D

 • El usuario interactúa con la interfaz.
• El controlador recibe la notificación de actuación del usuario.
• El controlador actúa sobre el modelo para cumplir con la petición del usuario.
• El controlador delega en las vistas para que se genere una determinada representación
del modelo.

12.1.4.STRUTS, phpMVC y sQeletor, frameworks

Para el desarrollo de este proyecto se optó por la elección de sQeletor como framework de
desarrollo. Se trata de un software desarrollado por la empresa iQual Ingenieros S.L.L. que
está basado en otro framework: el phpMVC. El phpMVC es a su vez un port de STRUTS, que
es un framework para aplicaciones corporativas bajo la plataforma de desarrollo J2EE.

A continuación describimos de forma sucinta la relación entre estos frameworks. En uno de

los anexos se puede obtener una lista más amplia de los framework disponibles en el mercado,
así como sus características principales.

12.1.4.1.J2EE
J2EE es una plataforma para el desarrollo y la implementación de aplicaciones corporativas
multinivel [AUM02]. Proporciona:

• Un modelo de desarrollo de componentes Web (Servlet, JSP) y de componentes

activos.
• Un conjunto de servicios.
• Un modelo de creación de módulos web (.war), de módulos EJB (.jar) y de módulos
corporativos (.ear), asociados a descriptores de despliegue en formato XML (ficheros
de configuración).
• Contenedores (web y EJB), para la realización de los componentes.

Para la implantación de una aplicación web bajo esta plataforma es necesario el uso de un
servidor de aplicaciones, el cual proporciona el contexto para la ejecución de los módulos.
Existen multitud de servidores de aplicaciones en el mercado.

J2EE está diseñado atendiendo al patrón de diseño de la arquitectura MVC. En este caso los
controladores son los servlets, y no son más que unas determinadas clases de java que
cumplen con una interfaz de diseño. La parte del modelo se implementa mediante EJB y/o
JavaBeans que son otra interfaz de clases. Y por último, la vista está implementada por JSP.
JSP son páginas HTML con fragmentos de código en Java. El funcionamiento de una
aplicación web con este tipo de arquitectura podría resumirse en los siguientes pasos:

Contenedor/ Contenedor
Servidor aplicaciones
Motor
Servlet EJB

Cliente Petición HTTP Aplicación

web 2 3 servidor
1

Respuesta HTTP 4

Servidor web

Arquitectura servidor de aplicaciones

• El cliente envía una petición HTTP al servidor web.

• El servidor web la transmite al servidor de aplicaciones.
• El servidor de aplicaciones llama al servlet, que es la clase encargada de gestionar esa
petición.
• Se acceden a otros componentes EJB y/o JavaBeans que pueden acceder a fuentes de
datos.
• Una vez modificado el dominio los componentes devuelven el resultado al servlet que
lo almacena en un entorno concreto (sesión, petición, etc.).
• El servlet envía los resultados hacia JSP.
• JSP recupera los datos almacenados por el Servlet y genera la respuesta HTTP que es
enviada al cliente.

12.1.4.2.STRUTS
STRUTS es un framework para aplicaciones web desarrollado por la Fundación de Apache
para J2EE. Se trata de un conjunto de clases que proporcionan una estructura escalable y fácil
de mantener para aplicaciones web complejas. Permite al diseñador del software centrarse en
la lógica de dominio, ya que resuelve una gran cantidad de problemas comunes a todas las
aplicaciones web, como son: la gestión de peticiones y respuestas http, el almacenamiento de
la información, etc.

12.1.4.3.phpMVC
PhpMVC es un framework para aplicaciones web. Consiste en un port de STRUTS, es decir,
es una traducción de STRUTS del lenguaje Java a PHP. Además de las clases de STRUTS,
phpMVC contiene otras clases que implementan parte de la plataforma de desarrollo J2EE,
que es el contexto de implantación de una aplicación que use STRUTS.

A continuación se muestra un diagrama con las principales clases de phpMVC.

phpmvc-config.xml RequestBase
Clases de phpmvc-config.xml

ApplicationConfig

HttpRequestBase ActionServer ActionForm

AppServerConfig RequestProcessor

AppServerContext Action

ResponseBase

HttpResponseBase Acciones

ActionDispatcher

Modelo de clases de phpMVC

El esquema de funcionamiento básico del phpMVC es muy sencillo. Existe un fichero de

configuración de la aplicación llamado phpmvc-config.xml en XML que contiene
información de la aplicación acerca de las acciones, formularios, bases de datos, etc. Durante
la ejecución del script PHP principal de la aplicación se realiza un análisis sintáctico de dicho
fichero, y el resultado de este análisis es un conjunto de clases que contienen toda la
información del fichero. Existen también dos clases asociadas a las peticiones y respuestas
que se envían a los clientes (HttpRequestBase y HttpResponseBase respectivamente). La
clase ActionServer es la encargada de recoger la petición, inicializarla y crear y llamar al
RequestProcessor para que la procese. El RequestProcessor a su vez creará la acción asociada
a la petición que será la encargada de llevar a cabo los cambios sobre el modelo del domino.
Para cada aplicación específica Action será la acción base de la que heredarán el resto de
acciones. Cuando una acción necesita recibir unos datos de entrada para su ejecución se
utiliza una clase ActionForm que los recoge, valida y almacena. Una vez procesada la acción
la clase ActionDispatcher es la encargada de generar la página de respuesta al cliente. Las
clases AppServerConfig y AppServerContext se encargan respectivamente de almacenar
variables y parámetros del servidor de la aplicación y de la aplicación en si. Esta
diferenciación procede del hecho de que phpMVC es un port de STRUTS y este framework
contiene las clases homólogas ServletConfig y ServletContext: la primera representa la
información de configuración de un servlet mientras que la segunda contiene la información
de configuración de la aplicación. Cada aplicación puede tener uno o varios servlets asociados
que son las clases que ejercen de controladores. En el caso de STRUTS se trata del
ActionServlet mientras que en el caso de phpMVC se trata del ActionServer.

12.1.4.4.sQeletor
sQeletor es un framework desarrollado por la empresa iQual Ingenieros S.L.L. basado en
phpMVC. Está constituido por un núcleo que es el phpMVC sobre el que se asientan varias
capas que añaden funcionalidad al framework.

Las principales funciones que añade sQeletor al phpMVC son:

• La integración de un motor de plantillas que permite separar el diseño de las páginas

del código PHP necesario para dotarlas de contenido dinámico. El motor está
integrado en el framework mediante el patrón de diseño de plugins. phpMVC soporta
el añadido de extensiones que no son más que clases que cumplen con una interfaz
concreta y que aportan una serie de funcionalidades nuevas. El motor de plantillas
usado es Smarty. Se trata de un potente motor de plantillas ampliamente testado,
reconocido, flexible y potente, que no solo permite incrustar variables en las plantillas
que van a ser resueltas en tiempo de ejecución del script, sino que también brinda una
serie de funciones modificadoras, directivas e incluso la posibilidad de añadir
extensiones propias.
 • La gestión de menús dinámicos, que son unos componentes frecuentemente usados
en aplicaciones y páginas web que permiten una mayor facilidad de navegación.

• Internacionalización. sQeletor incluye clases para el manejo de ficheros de recursos

de una manera sencilla y rápida. Estos ficheros almacenan toda la información de
cadenas de texto que se usan en la aplicación. De esta forma queda totalmente
independizada la lógica del dominio y sus eventos del mensaje dirigido al usuario que
los caracteriza, permitiendo que las aplicaciones sean traducidas a otros idiomas de
forma inmediata, sin más que proceder a la traducción de los ficheros de recursos.

• Además, sQeletor proporciona la integración con otras clases que permiten la gestión
de ficheros de configuración. Es muy común el uso de ficheros de configuración de
las aplicaciones que guardan información relativa a la instalación, opciones del
programa, etc. sQeletor incluye clases para la gestión de ficheros de configuración en
varios formatos incluido el XML.

12.1.5.Motores de plantillas
Un motor de plantillas es una librería de software que permite independizar los datos de una
página web de la forma en que se presentan. Su función principal es la de separar el trabajo de
los diseñadores del de los programadores. Los motores de plantillas básicamente se encargan
de la gestión de ficheros que contienen el código html de las páginas web. Estos ficheros se
llaman plantillas.

En los ficheros de plantillas se marca de alguna forma el contenido dinámico de la página, es

decir, el contenido que varía; que pudo haber sido extraído por ejemplo de una base de datos.
El motor de plantillas proporciona mecanismos para sustituir dichas variables por sus valores
concretos en cada momento. A esta funcionalidad esencial se pueden añadir otras capacidades
como la de “cacheado” de páginas y las funciones modificadoras de las variables, entre otras.

Existe una amplia variedad de motores de plantillas en el mercado para PHP entre ellos
Smarty, Fast Template, o Template Power. Uno de los más potentes y versátiles es Smarty, que
es el que utiliza sQeletor.

12.1.6.Motores de persistencia
Un motor de persistencia es una librería de software que se encarga del acceso a las bases de
datos relacionales en un programa orientado a objetos.
Uno de los paradigmas más usados en la programación es la programación orientada a
objetos, mientras que en los sistemas de gestión de bases de datos, el modelo más frecuente es
el de bases de datos relacionales. Por lo tanto tenemos que la integración de los dos suele ser
la forma más común de desarrollo. La principal función de un motor de persistencia consiste
en servir de traductor o intermediario entre estos dos niveles. Mientras que la lógica de la
aplicación maneja objetos, los sistemas de bases de datos relacionales utilizan registros. El
motor de persistencia se encarga de obtener los registros y convertirlos en objetos para su uso
en el programa, y a la inversa, de convertir los objetos en registros para su almacenaje
persistente en la base de datos.

Programa
orientado a Maneja objetos
objetos

Motor
de Traducción objetos/registros
Persistencia

Base
de Maneja registros
Datos

Motor de persistencia

La capa de persistencia de un programa contiene toda la lógica necesaria para leer, escribir y
borrar objetos desde y hacia un almacén de objetos permanente. Algunas de las características
que debería soportar un motor de persistencia son las siguientes:

• Varios tipos de mecanismos de persistencia: un mecanismo de persistencia es

cualquier tipo de tecnología que permita el almacenaje de información de forma
permanente. Pueden ser ficheros planos, bases de datos relacionales, bases de datos
jerárquicas, etc.
• Encapsulamiento completo de las funciones de persistencia: debería ser totalmente
transparente el mecanismo de persistencia al usuario, el cual únicamente haría uso de
los métodos para leer, escribir y borrar objetos.

• Acciones para varios objetos: frecuentemente en todo tipo de aplicaciones es

necesario realizar consultas de varios objetos para generar informes o listados. Una
capa robusta de persistencia debe ser capaz de devolver varios objetos
simultáneamente, y en general cualquier tipo de acción.

• Transacciones: deben ser soportadas transacciones, es decir, conjunto de acciones

sobre uno o varios objetos que se realizan todas o no se realiza ninguna. Y además de
cualquier duración de tiempo.

• Escalabilidad: tiene que ser posible añadir nuevas clases o cambiar el mecanismo de
persistencia.

• Identificadores de objeto: son atributos de los objetos, normalmente números, que

identifican unívocamente al objeto con el registro que lo contiene.

• Cursores: son mecanismos para obtener un subconjunto de los objetos requeridos a la

vez, ya que el manejo de grandes cantidades de registros puede ser inviable.

• Proxies (intermediarios): es un mecanismo complementario al uso de cursores. En

este caso, para listados grandes de registros se obtiene solamente el campo que
identifica el objeto/registro y alguno más que se muestre, y cuando se selecciona uno
de la lista se obtiene el resto de la información del objeto, que puede ser bastante
grande. De esta manera se ahorra en flujo de datos, que el caso de una aplicación web
puede ser muy importante (tráfico de red desde el servidor web al cliente).

• Múltiples arquitecturas: el motor de persistencia debe ser capaz de adaptarse a

múltiples arquitecturas: de dos niveles (cliente/servidor) o varios niveles.

• Varios sistemas de bases de datos: es importante que se de soporte para distintos

sistemas de bases de datos y versiones, y que además, el paso de un sistema a otro sea
de la forma más rápida y sencilla posible.
 • Múltiples conexiones: conexiones simultáneas a varios sistemas de bases de datos
para, por ejemplo, poder realizar el trasvase de información de uno a otro.

• Drivers nativos y no nativos: mecanismos de conexión usando drivers nativos

suministrados por el vendedor del sistema de bases de datos, así como otros genéricos
como ODBC y JDBC.

• Consultas SQL: soporte para ejecutar directamente consultas SQL sobre la bases de
datos. Aunque supone una violación del encapsulamiento del motor de persistencia, en
determinados casos puede ser necesario por motivos de rendimiento.

En definitiva, un motor de persistencia debe permitir centrarse a los diseñadores del software
en resolver el problema del dominio, y no en los mecanismos de almacenamiento de la
información.

En cuanto a los tipos de motores de persistencia, podríamos clasificarlos según tres modelos
básicos que son los más frecuentes:

• Objeto persistente: en este tipo de motor de persistencia todas las clases de la

aplicación, que se guardan cuando termina el programa, heredan de una clase
persistente que contiene los métodos para cargar, guardar y borrar el objeto. El
principal inconveniente de este modelo es que obliga a que las clases del dominio
hereden de las clases de persistencia.

• Intermediario de persistencia (persistence broker): el motor de persistencia

proporciona una clase principal, entre otras, a las que las clases del dominio solicitan
los objetos o cambios sobre estos.

• Lenguaje de consultas orientado a objetos (en inglés OQL, Object Query

Language): consiste en la extensión del SQL (Structured Query Language), que es el
lenguaje de consultas a las bases de datos, para que trabaje directamente con objetos.
Por ejemplo, una consulta típica del SQL como: "SELECT cod, nombre FROM
productos;" devolvería directamente los objetos en lugar de registros.
Existen casos reales de motores de persistencia que pueden combinar varios de estos modelos
en uno, como por ejemplo, un intermediario de persistencia con un lenguaje de consultas
orientado a objetos, según las necesidades de la aplicación.

En el mercado esta disponible una gran cantidad de motores de persistencia. Para la

plataforma de desarrollo en Java la lista es muy amplia: TopLink, Cocobase, Torque,
ObjectRelationalBridge, FrontierSuite, Castor, FreeFORM, Expresso, JrelationalFramework,
VBSF, Jgrinder, etcétera. En el caso de PHP la lista se reduce bastante: Propel, php-orm,
MetalL y algún otro software muy básico.

En este proyecto se ha usado el motor de persistencia PerenQen desarrollado por la empresa

iQual Ingenieros S.L.L. Se trata de un motor muy sencillo y fácil de usar, que se encaja dentro
del tipo de motores que utilizan una clase de intermediario de persistencia que se encarga de
las interacciones con el sistema de base de datos.

12.2.Diseño de la arquitectura
En este apartado se ofrece una descripción de la arquitectura de la aplicación, para ello
usaremos un enfoque analítico del sistema, es decir, partiremos de una visión general y global
para ir descendiendo a los niveles más concretos y detallados.

El tipo de arquitectura de la aplicación podría clasificarse como lo que comúnmente se conoce

como arquitectura en tres niveles, que deriva de una extensión de la arquitectura básica
cliente/servidor. En nuestro sistema intervienen tres partes diferenciadas. Por un lado tenemos
el cliente que se trataría de un navegador web, mediante el cual se tiene acceso a la aplicación,
en el nivel intermedio estaría el servidor web que alojaría todo el software de la aplicación, y
por último, tendríamos una serie de servidores de bases de datos por donde se encuentra
distribuida la información.
Este tipo de arquitectura tiene la ventaja de que es altamente escalable, versátil y permite la
distribución de los datos.

La lógica de la aplicación se distribuye entre los tres niveles.

En el nivel de los navegadores están las páginas en html que devuelve el servidor web junto
con una pequeña parte del código de la aplicación en JavaScript para la generación de los
menús dinámicos.

En el nivel de servidores de bases de datos estarán los sistemas de gestión de bases de datos.
La aplicación está preparada para trabajar con un conjunto heterogéneo de bases de datos y
contempla la posibilidad de añadir nuevos drivers para otros sistemas de bases de datos.

En el nivel del servidor web se encuentra el resto del código específico de la aplicación. Este
código podríamos dividirlo en varios paquetes de clases que realizan distintas funciones.
Estos paquetes son los que se muestran en el siguiente diagrama:
 sQeletor PerenQen

PC

phpMVC

Ext_Libs iQ_Libs

• PC: es el corazón de la aplicación que contiene las clases específicas del dominio del
problema e incluye: el dominio, las clases de autentificación, las clases de páginas, los
formularios, las vistas y las acciones.

• sQeletor: es un framework para aplicaciones web basado en phpMVC que añade

funcionalidad a este último.

• phpMVC: framework para el desarrollo de aplicaciones web en PHP basado en

STRUTS de java.

• PerenQen: motor de persistencia para PHP. Clases para el acceso a diversas bases de
datos.

• Ext_Libs: librerías externas para el desarrollo en PHP como son: PEAR,

phpLayersMenu y Smarty que son respectivamente: una biblioteca de clases con
múltiples funciones, una librería para la creación de menús dinámicos con javascript
desde PHP, y un motor de plantillas para independizar la presentación de las páginas
del contenido variable.
 • iQ_Libs: librerías de software de la empresa iQual Ingenieros para el desarrollo en
PHP que contienen clases para funciones de depuración, de registro y control, de
caché, de manejo de sesiones, etc.

12.2.1.PC
Es el núcleo de la aplicación, contiene las clases principales que aportan la solución al
problema concreto de la gestión de los inventarios. Son las clases específicas de esta
aplicación.

Las clases del paquete están divididas en dos grupos: las clases propias de la aplicación y las
que son extensiones del framework sQeletor. Se pueden dividir estas clases a su vez en varios
subpaquetes:

• Acciones (Actions): son clases que representan las acciones disponibles del dominio.
Constituyen la parte de controladores del modelo MVC. Cada acción contiene un
controlador para un caso de uso específico del sistema. Las acciones pueden agrupar
varias actividades con funciones comunes.

• Autenticación (Authentication): contiene clases para la autenticación de los usuarios

en el sistema.

• Negocio (Business): clases de la lógica de dominio. Cada clase representa alguna

entidad, actividad o relación del dominio del problema o clases relacionadas con la
lógica de negocio.

• Formularios (Forms): son las clases encargadas de recoger, validar y dar formato a
los datos de los formularios que se presentan al usuario del sistema. Incluyen
capacidades para mostrar los formularios html y para verificar los datos introducidos
por los usuarios.

• Página (Page): contiene la clase base que representa una página de la aplicación web.
Todas las páginas de la aplicación heredan de esta clase. Realiza tareas comunes a
todas las páginas como son la construcción de los menús, los formularios comunes,
etc. Se trata de la parte que implementa la vista en el modelo MVC.
• Páginas (Pages): contiene el conjunto de clases que representan las páginas de la
aplicación. Cada clase se encarga de construir una página web, usando la plantilla de
la misma con los datos aportados por el dominio.

• Vista (View): clase base que representa una vista del dominio, es decir, la información
de una entidad del dominio con solo sus atributos. Es la clase padre de todas las vistas
del dominio, y es la forma que tiene el dominio de responder a las acciones que se le
solicitan.

• Vistas (Views): son las clases que contienen cada una de las vistas que devuelve el
dominio.

• extSQeletor: extensiones al framework sQeletor.

A continuación se muestra un listado con las clases que componen el paquete PC con una
breve descripción de su cometido:

Grupo o Clase
IArque (bienes arqueológicos)
IArqueAction.php
IArqueEditAction.php
IArqueEditCalificacionAction.php
IArqueEditClasificacionAction.php
IArqueEditLocalidadesAction.php
IArqueEditMunicipiosAction.php
IArqueEditPropiedadAction.php
IArqueImageAction.php
IArqueInsertAction.php
IArqueQueryAction.php
IArqueShowAction.php
IArqui (bienes arquitectónicos)
IArquiAction.php
IArquiEditAction.php
IArquiEditCalificacionAction.php
IArquiEditClasificacionAction.php
IArquiEditCriteriosAction.php
IArquiEditEstadosAction.php
IArquiEditGradoAction.php
IArquiEditLocalidadesAction.php
IArquiEditMunicipiosAction.php
IArquiEditPropiedadAction.php
IArquiEditSiglosAction.php
IArquiEditTipoAction.php
IArquiEditTipologiasAction.php
IArquiEditUsoAction.php
IArquiImageAction.php
IArquiInsertAction.php
IArquiQueryAction.php
IArquiShowAction.php
IEtno (bienes etnográficos)
IEtnoAction.php
Acciones
Descripción
Clase padre de la que heredan el conjunto de acciones relacionadas con
el inventario insular de bienes arqueológicos.
Acciones relacionadas con la gestión de una ficha arqueológica.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de calificación del suelo.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de clasificación del suelo
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de localidades.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de municipios.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipos de propiedad.
Acciones relacionadas con la gestión de las imágenes de una ficha
arqueológica.
Inserción de una nueva ficha arqueológica.
Consultas al inventario de bienes arqueológico.
Acciones relacionadas con la obtención de información del inventario.
Clase padre de la que heredan el conjunto de acciones relacionadas con
el inventario insular de bienes arquitectónicos.
Acciones relacionadas con la gestión de una ficha arquitectónica.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de calificación del suelo.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de clasificación del suelo.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de criterios de catalogación.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de estados.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de grados de protección.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de localidades.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de municipios.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipos de propiedad.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de siglos.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipos de intervención.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipologías de inmuebles.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de usos actuales.
Acciones relacionadas con la gestión de las imágenes de una ficha
arquitectónica.
Inserción de una nueva ficha arquitectónica.
Consultas al inventario de bienes arquitectónicos.
Acciones relacionadas con la obtención de información del inventario.
Clase padre de la que heredan el conjunto de acciones relacionadas con
el inventario insular de bienes etnográficos.
IEtnoEditAction.php
IEtnoEditActividadesAction.php
IEtnoEditAntiguedadAction.php
IEtnoEditCalificacionAction.php
IEtnoEditClasificacionAction.php
IEtnoEditEstadoAction.php
IEtnoEditFragilidadAction.php
IEtnoEditGradoAction.php
IEtnoEditLocalidadesAction.php
IEtnoEditMunicipiosAction.php
IEtnoEditPropiedadAction.php
IEtnoEditTipoAction.php
IEtnoEditTiposAction.php
IEtnoEditUsoAction.php
IEtnoEditValorAction.php
IEtnoImageAction.php
IEtnoInsertAction.php
IEtnoQueryAction.php
IEtnoShowAction.php
Mean
CambiarIdiomaAction.php
CambiarNavegacionAction.php
CambiarPaginaNavegacionAction.php
CambiarTipoAction.php
CambiarZonaAction.php
LogAction.php
LoginAction.php
LogoutAction.php
MostrarAyudaAction.php
NuevaSugerenciaAction.php
PageAction.php
UserValidator.php
Grupo o Clase
IWatchman.php
WatchmanImpl.php
Acciones relacionadas con la gestión de una ficha etnográfica.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de actividades.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de antigüedad.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de calificación del suelo.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de clasificación del suelo.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de estados.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de fragilidad.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de grado de protección.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de localidades.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de municipios.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipos de propiedad.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipo de intervención.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de tipos de bienes.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de uso actual.
Acciones relacionadas con la gestión de un registro de la tabla auxiliar
de valor.
Acciones relacionadas con la gestión de las imágenes de una ficha
etnográfica.
Inserción de una nueva ficha etnográfica.
Consultas al inventario de bienes etnográficos.
Acciones relacionadas con la obtención de información del inventario.
Cambio de idioma en la aplicación.
Cambiar la paginación de los registros de un listado.
Cambiar la paginación de los registros de un listado.
Cambiar tipo de bien activo.
Cambiar región activa.
Funciones de log.
Inicio de sesión.
Fin de sesión.
Mostrar páginas de ayuda.
Enviar sugerencias.
Grupo de acciones relacionadas con la visualización de las páginas.
Acciones para la validación de usuarios.
Autenticación
Descripción
Interfaz para clases de autenticación de usuarios.
Acciones relacionadas con la gestión de una ficha arqueológica.

Grupo o Clase
BaseObject.php
Region.php
User.php
IDomainService.php
DomainServiceImpl.php
Grupo o Clase
IArque (bienes arqueológicos)
IArqueCalificacionForm.php
IArqueClasificacionForm.php
IArqueEditForm.php
IArqueImageForm.php
IArqueLocalidadesForm.php
IArqueMunicipiosForm.php
IArquePropiedadForm.php
IArqui (bienes arquitectónicos)
IArquiCalificacionForm.php
IArquiClasificacionForm.php
IArquiCriteriosForm.php
IArquiEditForm.php
IArquiEstadosForm.php
IArquiGradoForm.php
IArquiImageForm.php
IArquiLocalidadesForm.php
IArquiMunicipiosForm.php
IArquiPropiedadForm.php
IArquiSiglosForm.php
IArquiTipoForm.php
IArquiTipologiasForm.php
IArquiUsoForm.php
IEtno (bienes etnográficos)
IEtnoActividadesForm.php
IEtnoAntiguedadForm.php
IEtnoCalificacionForm.php
IEtnoClasificacionForm.php
IEtnoEditForm.php
IEtnoEstadoForm.php
IEtnoFragilidadForm.php
IEtnoGradoForm.php
IEtnoImageForm.php
IEtnoLocalidadesForm.php
IEtnoMunicipiosForm.php
IEtnoPropiedadForm.php
IEtnoTipoForm.php
IEtnoTiposForm.php
IEtnoUsoForm.php
IEtnoValorForm.php
Mean
LoginForm.php
NavegacionForm.php
Negocio
Descripción
Clase base para todos los objetos del dominio.
Representa una zona con servidor de bases de datos para la aplicación.
Representa un usuario de la aplicación.
Interfaz de clase para el dominio.
Clase que implementa la interfaz de dominio. Representa el dominio
del problema, es decir, encapsula el sistema. Es a través de esta clase
por donde se accede a las acciones sobre la aplicación.
Formularios
Descripción
Formulario para la calificación del suelo.
Formulario para la clasificación del suelo.
Formulario para la recogida de datos de una ficha arqueológica.
Formulario para el upload de imágenes de una ficha arqueológica.
Formulario para las localidades.
Formulario para los municipios.
Formulario para los tipos de propiedad.
Formulario para la calificación del suelo.
Formulario para la clasificación del suelo.
Formulario para la recogida de datos de una ficha arquitectónica.
Formulario para la recogida de datos de una ficha arquitectónica.
Formulario para los estados.
Formulario para los grados de protección.
Formulario para el upload de las imágenes de una ficha arquitectónica.
Formulario para las localidades.
Formulario para los municipios.
Formulario para los tipos de propiedad.
Formulario para los siglos.
Formulario para el tipo de intervención.
Formulario para las tipologías de inmuebles.
Formulario para los usos actuales.
Formulario para las actividades.
Formulario para las antigüedades.
Formulario para la calificación del suelo.
Formulario para la clasificación del suelo.
Formulario para la recogida de datos de una ficha etnográfica.
Formulario para los estados.
Formulario para la fragilidad.
Formulario para los grados de protección.
Formulario para el upload de imágenes de una ficha etnográfica.
Formulario para las localidades.
Formulario para los municipios.
Formulario para los tipos de propiedad.
Formulario para los tipos de intervención.
Formulario para los tipos de bienes.
Formulario para el uso actual.
Formulario para el valor.
Formulario para el inicio de sesión del usuario.
Formulario para la barra de navegación por los registros de un listado

SugerenciasForm.php
Grupo o Clase
BasePage.php
Grupo o Clase
IArque (bienes arqueológicos)
IArqueCalificacionPage.php
IArqueClasificacionPage.php
IArqueConfirmDelPage.php
IArqueDetailPage.php
IArqueEditPage.php
IArqueImagePage.php
IArqueInsertPage.php
IArqueListPage.php
IArqueLocalidadesPage.php
IArqueMessagePage.php
IArqueMunicipiosPage.php
IArquePropiedadPage.php
IArqueQueryPage.php
IArqueTablePage.php
IArqui (bienes arquitectónicos)
IArquiCalificacionPage.php
IArquiClasificacionPage.php
IArquiConfirmDelPage.php
IArquiCriteriosPage.php
IArquiDetailPage.php
IArquiEditPage.php
IArquiEstadosPage.php
IArquiGradoPage.php
IArquiImagePage.php
IArquiInsertPage.php
IArquiListPage.php
IArquiLocalidadesPage.php
IArquiMessagePage.php
IArquiMunicipiosPage.php
IArquiPropiedadPage.php
IArquiQueryPage.php
IArquiSiglosPage.php
IArquiTablePage.php
IArquiTipologiasPage.php
IArquiTipoPage.php
IArquiUsoPage.php
IEtno (bienes etnográficos)
IEtnoActividadesPage.php
IEtnoAntiguedadPage.php
IEtnoCalificacionPage.php
IEtnoClasificacionPage.php
IEtnoConfirmDelPage.php
IEtnoDetailPage.php
IEtnoEditPage.php
IEtnoEstadoPage.php
IEtnoFragilidadPage.php
(paginación).
Formulario para la recogida de sugerencias de la aplicación.
Página
Descripción
Clase base para todos las páginas web de la aplicación. Realiza
acciones comunes a todas las páginas, como la generación de menús.
Páginas
Descripción
Página que muestra la tabla auxiliar de calificación del suelo.
Página que muestra la tabla auxiliar de clasificación del suelo.
Página para la confirmación de borrado de una ficha.
Página que muestra una ficha en detalle.
Página para la modificación de una ficha.
Página para mostrar una imagen.
Página para insertar una nueva ficha.
Página para mostrar el resultado de una consulta al inventario.
Página que muestra la tabla auxiliar de localidades.
Página para mostrar un mensaje al usuario.
Página que muestra la tabla auxiliar de municipios.
Página que muestra la tabla auxiliar de tipos de propiedad.
Página para realizar una consulta por campos.
Página para mostrar la tabla con todos los registros del inventario.
Página que muestra la tabla auxiliar de calificación del suelo.
Página que muestra la tabla auxiliar de clasificación del suelo.
Página para la confirmación de borrado de una ficha.
Página que muestra la tabla auxiliar de criterios de catalogación.
Página que muestra una ficha en detalle.
Página para la modificación de una ficha.
Página que muestra la tabla auxiliar de calificación del suelo.
Página que muestra la tabla auxiliar de grados de protección.
Página para mostrar una imagen.
Página para insertar una nueva ficha.
Página para mostrar el resultado de una consulta al inventario.
Página que muestra la tabla auxiliar de localidades.
Página para mostrar un mensaje al usuario.
Página que muestra la tabla auxiliar de municipios.
Página que muestra la tabla auxiliar de tipo de propiedad.
Página para realizar una consulta por campos.
Página que muestra la tabla auxiliar de siglos.
Página para mostrar la tabla con todos los registros del inventario.
Página que muestra la tabla auxiliar de tipologías.
Página que muestra la tabla auxiliar de tipo de intervención.
Página que muestra la tabla auxiliar de uso actual.
Página que muestra la tabla auxiliar de actividades.
Página que muestra la tabla auxiliar de antigüedades.
Página que muestra la tabla auxiliar de calificación del suelo.
Página que muestra la tabla auxiliar de clasificación del suelo.
Página para la confirmación de borrado de una ficha.
Página que muestra una ficha en detalle.
Página para la modificación de una ficha.
Página que muestra la tabla auxiliar de estados.
Página que muestra la tabla auxiliar de fragilidad.
 IEtnoGradoPage.php
IEtnoImagePage.php
IEtnoInsertPage.php
IEtnoListPage.php
IEtnoLocalidadesPage.php
IEtnoMessagePage.php
IEtnoMunicipiosPage.php
IEtnoPropiedadPage.php
IEtnoQueryPage.php
IEtnoTablePage.php
IEtnoTipoPage.php
IEtnoTiposPage.php
IEtnoUsoPage.php
IEtnoValorPage.php
Mean
AccesibilidadPage.php
AdminPage.php
AgradecimientosPage.php
AyudaEmergentePage.php
EnlacesPage.php
ImagenPage.php
InicioPage.php
IntroPage.php
LoginPage.php
MensajePage.php
PrincipalPage.php
QueEsPage.php
Grupo o Clase
BaseView.php
Grupo o Clase
RegionView.php
UserView.php
Grupo o Clase
ExtendedBaseAction.php
ExtendedBaseRequest.php
Se pueden ver en el diagrama de clases las relaciones entre las distintas clases del paquete.
Por un lado tenemos las clases con funciones de control de las acciones, estas se corresponden
con la parte de controladores del modelo MVC. Estas clases son: los formularios que recogen
los datos suministrados por los usuarios y las acciones que el sistema permite ejecutar.
Página que muestra la tabla auxiliar de grados de protección.
Página para mostrar una imagen.
Página para insertar una nueva ficha.
Página para mostrar el resultado de una consulta al inventario.
Página que muestra la tabla auxiliar de localidades.
Página para mostrar un mensaje al usuario.
Página que muestra la tabla auxiliar de municipios.
Página que muestra la tabla auxiliar de tipos de propiedad.
Página para realizar una consulta por campos.
Página para mostrar la tabla con todos los registros del inventario.
Página que muestra la tabla auxiliar de tipo de intervención.
Página que muestra la tabla auxiliar de tipos de bienes.
Página que muestra la tabla auxiliar de usos actuales.
Página que muestra la tabla auxiliar de valor.
Página que muestra un texto de accesibilidad de la aplicación.
Página de administración de la aplicación.
Página que muestra un texto con los agradecimientos.
Página que muestra la ayuda emergente.
Página de enlaces.
Página para mostrar una imagen.
Página de inicio.
Página de introducción.
Página para el inicio de sesión del usuario.
Página para mostrar mensajes.
Página principal.
Página con un texto breve de explicación del proyecto.
Vista
Descripción
Vista padre de todas las vistas del dominio.
Vistas
Descripción
Guarda la información de una región.
Guarda la información de un usuario.
Extensiones de sQeletor
Descripción
Acción base de la cual heredan el resto de acciones de la aplicación.
Contiene métodos para el manejo de ficheros de configuración de la
aplicación en XML.
Hereda de sQeletor para independizar del framework y poder añadir
funcionalidad propia en un futuro.
Por otro lado tenemos la lógica de dominio, que incluye las clases que representan las
entidades del dominio del problema.

En tercer lugar están las clases relacionadas con la presentación del resultado de las acciones
sobre el dominio. Estas clases pertenecen al grupo de las vistas del modelo MVC.

Y por último están los objetos de transferencia de datos. Este tipo de objetos se crean como
portadores de los datos del dominio. Se trata básicamente de las mismas clases del dominio
que son visibles desde fuera de este, y a las que se les sustraen sus métodos, quedando de esta
forma solamente sus atributos.
 12.2.1.1.Ejemplo de funcionamiento
Para aclarar el funcionamiento de la aplicación veremos en este apartado como se procesa una
petición para un caso concreto. El caso seleccionado es la petición que muestra la página del
listado de los bienes etnográficos.

A continuación podemos ver los diagramas de secuencia de esta acción. El primero representa
los pasos que se dan para obtener los datos de la página que queremos mostrar y el segundo
representa la construcción de la página html.

La acción que representamos se produce cuando el usuario pone en el navegador, ya sea

directamente, o a través de un enlace desde otros documentos, la siguiente dirección URL:

URL: http://host/PC/Main.php?do=IEtnoShowAction&method=showTable

Main.php es el script principal de la aplicación, todas las peticiones se recogen en este script.
El usuario en ningún momento hace una petición a través de otro script PHP.
El valor para el parámetro do, en este caso IEtnoShowAction, le indica a la aplicación cual
es la acción que queremos realizar. En el fichero de configuración phpMVC-config.xml estará
especificado que clase es la encargada de gestionar esta acción. En este caso existe una clase
cuyo nombre es igual al de la acción.
Hay que distinguir entre la acción lógica, que representa una actuación del usuario sobre la
aplicación, y la clase acción que implementa dicha actuación. En ocasiones varias acciones
lógicas pueden ser agrupadas para ser gestionadas por una única clase acción. Esto permite
agrupar acciones que tienen cosas en común y evita hacer demasiado grande el fichero de
configuración del phpMVC. El parámetro method permite en estos casos indicar a la clase
que gestiona la acción que método se encarga se atender esa petición. Para el ejemplo, existe
una clase IEtnoShowAction que gestiona varias acciones, entre ellas, la de mostrar una tabla
(showTable) que es uno de sus métodos.
Tanto el nombre del parámetro ‘do’ como el de ‘method’ son configurables, no tienen porque
llamarse de esa forma.

En este primer diagrama se puede ver como se procesa la primera parte de la petición. En ella
se dan los siguientes pasos:
 1. El RequestProcessor es la clase de phpMVC encargada de procesar la petición. Lo
primero que hace es crear la clase que implementa esta acción. En este caso la clase
IEtnoShowAction.
2. Se llama el método showTable de la clase IEtnoShowAction indicado en la url. Este
método es el encargado de actuar sobre el dominio para llevar a cabo la acción
solicitada por el usuario.
3. La clase IEtnoShowAction obtiene una referencia al DomainServiceImpl que es la
clase que representa el dominio.
4. Se crea una consulta, en donde se le especifica al motor de persistencia que objetos
queremos obtener de la base de datos.
5. Se le solicitan al dominio los registros indicados en la consulta.
6. El dominio solicita al motor de persistencia (PersistenceBrokerImpl) un intermediario
(broker), que es el encargado de gestionar la petición de registros de un a tabla.
7. El PersistenceBrokerImpl crea el intermediario para que lo use el dominio.
8. El dominio recibe in intermediario del motor de persistencia para hacer peticiones de
registros a una tabla.
9. El dominio solicita al intermediario los registros que especificó en la consulta
(PEQuery).
10. El intermediario consulta la base de datos y devuelve los registros que cumplen la
condición de la consulta.
11. Una vez el dominio ha obtenido los registros de la bases de datos se los da a la acción
que los solicitó.
12. La acción guarda los registros obtenidos en la petición, de donde los recogerán las
clases encargadas de crear la página html de respuesta.

Una vez ejecutada la acción, el RequestProcessor continúa procesando la petición según lo

que le indique la acción. En este caso la acción una vez ejecutada redirige la aplicación hacia
mostrar la página de listados. Para ello se ejecutan los siguientes pasos:
1. El RequestProcessor crea la clase BaseActionDispatcher. Cada acción al terminar
puede redirigir la aplicación hacia la ejecución de otra acción (cadenas de acciones) o
entregar un recurso al cliente. Las posibles vías de consecución de una acción se
especifican en el fichero de configuración de phpMVC. En este caso la acción no
llama a otras acciones sino que va a entregar al cliente la página html con los registros.
La clase encargada de hacer esta entrega es el BaseActionDispatcher.
2. El RequestProcessor delega en el BaseActionDispatcher la tarea de dirigir la salida de
la página al cliente.
3. El método invoke llama a la función encargada de generar la respuesta, según de que
tipo sea esta. El phpMVC permite generar respuestas de distinto tipo al HTML y
usando otros protocolos aparte de HTTP, como por ejemplo vía e-mail o cualquier
otro.
4. Se construye la respuesta.
5. Se crea una instancia de la clase TemplateEngineFactory que es la encargada de
construir el motor de plantillas. Esta clase hace que no esté cableado en el código el
motor de plantillas que hay que usar, sino que se pueda alternar entre varios.
6. Se le pide al TemplateEngineFactory que devuelva una instancia del motor de
plantillas.
7. El TemplateEngineFactory crea el motor de plantillas.
8. Se crea la página IEtnoShowPage, que es la clase encargada de asignar el contenido
obtenido de la base de datos a la plantilla de la página de respuesta.
9. Se le indica a la clase IEtnoShowPage que asigne valores a las variables de la plantilla
de la página. Existe una plantilla de listado de bienes etnográficos en html que no
contiene valores concretos, sino que son asignados durante este paso.
10. Se le indica al motor de plantillas que resuelva la plantilla, es decir, que donde aparece
una variable en la plantilla la sustituya por el valor para esta petición (contenido
dinámico).
11. El motor de plantillas devuelve la página montada y lista para ser enviada al
navegador web.
12. Se guarda la página en la clase que contiene la respuesta (HttpResponseBase) y
finaliza el método serviceResponse.
13. Se solicita la clase HttpResponseBase la página que el método serviceResponse
guardó.
14. HttpResponseBase nos da la página que hay que enviar y se manda al cliente mediante
un echo.
 12.2.2.Arquitectura distribuida
El diseño de la aplicación está basado en la posibilidad de que esta acceda a un conjunto de
bases de datos heterogéneo, distribuido geográficamente en distintos servidores. De esta
manera la aplicación se comportaría como un multiplexador capaz de conectar al usuario
potencial con cualquiera de las bases de datos a las que tiene acceso la aplicación.

Para el usuario final de la aplicación existe un único punto de acceso a los datos
correspondiente a la aplicación web. En cualquier momento se trabaja con una zona activa y
es posible alternar entre varias. Este fue el principal requisito que guió el diseño de la
aplicación, y varios son los puntos del diseño que soportan este requisito.

En primer lugar existe un fichero de configuración en el servidor web que contiene la lista de
bases de datos que hay disponibles. Se optó por utilizar un fichero en formato XML por su
extendido uso, flexibilidad y facilidad de gestión. Este fichero se llama DBServers-
config.xml. A continuación se muestra un ejemplo del contenido del fichero:

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!--
* DBServers-config.xml
*
*
===========================================================================
===
*
* U.L.P.G.C. - Universidad de las Palmas de Gran Canaria.
* E.U.I. - Escuela Universitaria de Informática.
* P.F.C. - Proyecto Fin de Carrera.
* Título - Sistema de gestión distribuida
* del patrimonio cultural bajo Internet.
* Autor - José Celano Martín. <jcelano@tiscali.es>
* Tutores - Antonio Ocón Carreras y Enrique Rubio Royo.
* Fecha - 2002-2005.
*
*/
-->

<!--
Fichero de configuración de los servidores de
bases de datos de la aplicación

Engines:
PE_DBENGINE_MYSQL
PE_DBENGINE_POSTGRESQL
PE_DBENGINE_MYSQL
PE_DBENGINE_ORACLE
PE_DBENGINE_ODBC

Al modificar este fichero los cambios no tendrán efecto

Hasta que el usuario inicie una nueva sesión.
-->

<DBServers-config>

<!-- Etnografía -->

<server zone = "grancanaria"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOGC"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
grancanaria-IETNO_DB
</server>
<server zone = "tenerife"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOTF"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
tenerife-IETNO_DB
</server>
<server zone = "fuerteventura"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOFU"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
 DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
fuerteventura-IETNO_DB
</server>
<server zone = "lanzarote"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOLA"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lanzarote-IETNO_DB
</server>
<server zone = "lapalma"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOLP"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lapalma-IETNO_DB
</server>
<server zone = "lagomera"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOLG"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lagomera-IETNO_DB
</server>
<server zone = "elhierro"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOEH"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
elhierro-IETNO_DB
</server>

<!-- Arqueología -->

<server zone = "grancanaria"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUEGC"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
grancanaria-IARQUE_DB
</server>
<server zone = "tenerife"
type = "IARQUE_DB"
host = "www.dbhost.net"
 DBName = "IARQUETF"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
tenerife-IARQUE_DB
</server>
<server zone = "fuerteventura"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUEFU"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
fuerteventura-IARQUE_DB
</server>
<server zone = "lanzarote"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUELA"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP" port = "5432">
lanzarote-IARQUE_DB
</server>
<server zone = "lapalma"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUELP"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lapalma-IARQUE_DB
</server>
<server zone = "lagomera"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUELG"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lagomera-IARQUE_DB
</server>
<server zone = "elhierro"
type = "IARQUE_DB"
host = "www.dbhost.net"
DBName = "IARQUEEH"
tablespace = "PARQUEOLOGICO"
userstablespace = "PARQUEOLOGICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
elhierro-IARQUE_DB
</server>

<!-- Arquitectura -->

<server zone = "grancanaria"
 type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUIGC"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP" port = "5432">
grancanaria-IARQUI_DB
</server>
<server zone = "tenerife"
type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUITF"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
tenerife-IARQUI_DB
</server>
<server zone = "fuerteventura"
type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUIFU"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
fuerteventura-IARQUI_DB
</server>
<server zone = "lanzarote"
type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUILA"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lanzarote-IARQUI_DB
</server>
<server zone = "lapalma"
type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUILP"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lapalma-IARQUI_DB
</server>
<server zone = "lagomera"
type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUILG"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
lagomera-IARQUI_DB
</server>
<server zone = "elhierro"
 type = "IARQUI_DB"
host = "www.dbhost.net"
DBName = "IARQUIEH"
tablespace = "PARQUITECTONICO"
userstablespace = "PARQUITECTONICO"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
elhierro-IARQUI_DB
</server>

</DBServers-config>

Como se puede observar existe una estructura básica que se repite:

<server zone = "grancanaria"
type = "IETNO_DB"
host = "www.dbhost.net"
DBName = "IETNOGC"
tablespace = "PETNOGRF"
userstablespace = "PETNOGRF"
DBEngine = "PE_DBENGINE_POSTGRESQL"
protocol = "TCP"
port = "5432">
grancanaria-IETNO_DB
</server>

Cada elemento server especifica a la aplicación una base de datos disponible. Los atributos
son:
• zone: clave de la zona que representa la división geográfica o lógica de las bases de
datos. En el caso del ejemplo existe una zona por isla.
• type: clave del tipo de bien.
• host: nombre o dirección IP del host donde se encuentran hospedadas las bases de
datos.
• DBName: nombre de la base de datos.
• tablespace: espacio de tablas (agrupación lógica de tablas que usan algunos sistemas
de bases de datos) donde se encuentran las tablas de datos.
• usertablespace: espacio de tablas de las tablas que contienen información sobre los
roles de usuarios.
• DBEngine: tipo de motor de base de datos.
• protocol: protocolo de conexión a la base de datos.
• port: puerto de conexión a la base de datos.

Este fichero es analizado al inicio de cada sesión de usuario para comprobar si se han añadido
nuevas zonas. Una vez extraída toda la información que contiene, es la clase que representa el
dominio (DomainServiceImpl) la encargada de almacenar dicha información. Como se puede
observar en el diagrama la clase ExtendedBaseAction, que es la clase padre de todas las
acciones de la aplicación, se encarga de hacer el análisis sintáctico del fichero de
configuración de los servidores de bases de datos. Lo hace mediante el uso de la clase Config
de PEAR. Una vez analizado el fichero, se guarda la información en la clase WatchmanImpl,
en el atributo dbservers, que no es más que un vector con la información de las distintas
zonas. Los datos del usuario y región actuales son almacenados en dos instancias de las clases
User y Region respectivamente, a partir de estos dos objetos, el dominio obtiene los
parámetros necesarios para las conexiones a las bases de datos mediante el motor de
persistencia.
 12.2.3.phpMVC y sQeletor
Aunque phpMVC y sQeletor constituyen dos paquetes diferenciados están íntimamente
ligados. sQeletor consiste en una ampliación de las características de phpMVC. Esta
ampliación se basa en una extensión de sus clases por un lado, y en una incorporación de
nuevas clases por otro. En el siguiente diagrama de clases podemos ver como se
interrelacionan las clases entre sí en el modelo de arquitectura MVC.
Se puede resumir el funcionamiento del modelo MVC en los siguientes pasos:

1. El cliente envía una petición al servidor que es encapsulada en la clase

HttpRequestBase.

2. Se activa un controlador (ActionServer) que es el encargado de gestionar la petición.

3. El controlador delega la ejecución de la petición concreta al RequestProcessor, que

usará la clase ActionForm para validar los datos de entrada para la acción (si los hay),
y creará y llamará a la acción concreta solicitada (Action).

4. La acción realizará peticiones al dominio, cambiando su estado interno.

5. Posteriormente el dominio, después de procesar las peticiones de las acciones,

actuando por ejemplo sobre una base de datos, devolverá unas vistas del modelo
interno.

6. Los objetos que devuelve el dominio, y otros que se almacenan, son conocidos como
objetos de transferencia de datos, porque su única función es la de servir de soporte
para el trasporte de datos entre las distintas partes de la aplicación.

7. El ActionDispatcher es la clase encargada de construir la respuesta al cliente. Para ello

usa los datos obtenidos del dominio y las páginas (Page). Estas páginas son los objetos
que cargan las plantillas con sus valores actuales (contenido dinámico).

8. Se le envía la respuesta (HttpResponseBase) al cliente.

 12.2.4.PerenQen
PerenQen es un motor de persistencia desarrollado por la empresa iQual Ingenieros. Su diseño
está vertebrado entorno a una clase principal que hace de intermediario, entre las clases del
dominio de la aplicación, y los sistemas de gestión de bases de datos. Dicha clase es el
intermediario de persistencia (PersistenceBroker).

Su funcionamiento es sencillo: existe un fichero de mapeo (PrQDBMapping.php) en el que el

usuario del motor especifica las tablas y campos del modelo de la estructura de datos. Para las
tablas se especifica una clave que sirve como código de referencia, y el nombre de la tabla en
la base de datos. De esta manera se independiza la aplicación de cualquier cambio en los
nombres reales de las tablas.

Una vez configurado e instalado el motor, solo es necesario solicitar un objeto de la clase
PersistenceBrokerImpl al servidor de intermediarios. Con este objeto se hacen las peticiones
de acceso a una tabla de la base de datos.

El motor soporta actualmente dos bases de datos: Oracle y PostgreSQL, y permite añadir
drivers para otro tipo de sistemas. En la siguiente tabla se muestra una lista de las clases que
lo configuran:

Vistas
Grupo o Clase Descripción
Connection.php Gestiona una conexión a una base de datos.
ConnectionsServer.php Clase responsable del control y gestión de las conexiones.
Criteria.php Contiene un criterio para una consulta.
CriteriaArray.php Contiene un conjunto de criterios.
Field.php Representa un campo de una tabla con su tipo y valor.
IConnectionsServer.php Interfaz para clases de servidores de conexiones.
IPersistenceBroker.php Interfaz para clases de intermediarios de persistencia.
IPersistenceBrokerServer.php Interfaz para clases de servidores de persistencia.
PBKey.php Llave a un intermediario de persistencia. Contiene información como
el tipo de base de datos, su ubicación, el usuario que accede, etc. En
definitiva, representa unívocamente un acceso a una base de datos.
PBTableMap.php Se encarga de la gestión del fichero de correspondencias (mapping)
entre la aplicación y la base de datos.
PEQuery.php Representa una consulta a la base de datos.
PersistenceBrokerImpl.php Es un intermediario de persistencia, la principal clase encargada de la
gestión de los accesos a la base de datos, de cara al usuario del motor
de persistencia.
PersistenceBrokerServerImpl.php Es el servidor de intermediarios de persistencia. Se encarga de
gestionar y entregar intermediarios de persistencia a la aplicación.
SQLCommon.php Driver abstracto del que heredan todos los drivers.
SQLOracle.php Driver para Oracle.
SQLPostgre.php Driver para PostgreSQL.
En el diagrama de clases de PerenQen podemos observar como se relacionan las clases del
motor. El dominio interactúa con el motor a través de las clases: PEQuery,
PersistenceBrokerServerImpl, y PBKey. Mediante PEQuery se especifica la consulta,
PersistenceBrokerServerImpl devuelve un PersistenceBrokerImpl que se usa como
intermediario para acceder a una tabla, y PBKey que representa una llave de acceso al motor,
y con la que se le indica este la base de datos a la que se quiere acceder.

En el diagrama de secuencia que se encuentra a continuación se muestra un caso típico de uso

del motor que consiste en solicitarle un conjunto de registros de una tabla. Como se puede ver
en el diagrama los pasos son los siguientes:

1. Se crea el servidor de intermediarios de persistencia. No es necesario crear esta clase

en cada consulta sino que puede tratarse de un atributo del dominio o una clase
singleton, dependiendo de cómo se diseñe el sistema. En el caso de esta aplicación el
servidor de intermediarios se inicializa la primera vez que se llama al script en la
sesión, y permanece como un atributo del dominio, pudiéndose acceder a él desde
cualquier método del dominio.
2. Se le solicita al servidor de persistencia una llave de acceso a una base de datos. Para
ello se le pasan ciertos parámetros como el nombre del host, el de la base de datos, el
del usuario, etcétera.
3. Se solicita un intermediario de persistencia al servidor para acceder a la tabla que
apunta el PBKey.

4. El servidor de persistencia crea el intermediario y devuelve una referencia.

5. Se crea una instancia de la clase PBQuery en donde se pueden establecer las

condiciones que deben cumplir los registros para la consulta a la tabla.

6. Se crea una consulta y se configura. Le indicamos los criterios de búsqueda, tipo de

ordenación del resultado etc.

7. Se solicita al intermediario (broker) los registros que cumplan las condiciones de la

consulta contenidas en el PBQuery.

8. El intermediario nos devuelve un vector con dichos registros.

9. Finalmente, se valida toda la operación. En este tipo de consultas no tiene ninguna

función ya que no se ha hecho ninguna modificación en la base de datos, pero es
necesario hacerlo.
13.Justificación y evaluación de las herramientas utilizadas
Para el desarrollo de este proyecto se utilizaron un conjunto de herramientas de software
ampliamente difundido y testeado.

• PHP: se trata de un lenguaje de programación muy difundido para aplicaciones web,

con un amplio soporte de librerías, foros, y ayuda en línea. Por lo demás, se trata de un
lenguaje sencillo a la vez que potente, con una baja curva de aprendizaje. Existe una
gran cantidad de profesionales y es la solución adoptada por un gran número de
aplicaciones muy conocidas. No es necesario la instalación de ningún tipo de máquina
virtual y su rendimiento y velocidad son muy altos. En cuanto a su facilidad de
implantación, la mayoría de empresas de servicios de hosting ofrecen PHP a un precio
muy asequible.

Hay que añadir las ventajas de tratarse de un software de código abierto, gratutio y
multiplataforma.

Por contra se ha objetado que no llega al nivel de otros lenguajes como Java en cuanto
a soporte para la programación orientada a objetos, ni dispone de software para
aplicaciones de gran tamaño como frameworks, motores de persistencia, etc.

• phpMVC: aunque se trata de un framework poco conocido y que aún es una versión
beta, se eligió por tratarse de un port de STRUTS para PHP. STRUTS es un
framework ampliamente usado. Esta elección facilitaría el paso del personal empleado
en el desarrollo de aplicaciones web de uno a otro framework sin mucha dificultad.
Por otro lado se trata de uno de los framework en PHP con más perspectivas de futuro.
Además es uno de los frameworks de código abierto que están en un grado más
avanzado de desarrollo. Al final del documento hay una lista de los distintos
frameworks disponibles en el mercado con una breve reseña de sus características para
cada uno de ellos.

• PostgreSQL: es el sistema de bases de datos gratuito que ofrece una mayor potencia,
fiabilidad y prestaciones. Otro muy usado y también gratuito, que se consideró para la
elección pero fue desestimado es MySQL, sistema de gestión de bases de datos
normalmente utilizado para proyectos más pequeños o que no requieren de
 capacidades tan avanzadas debido a que no soporta transacciones, roles, ni
subconsultas, herramientas fundamentales para este tipo de aplicación.

• PerenQen: se eligió este sistema porque cumplía con todas las características
necesarias y deseables. Entre otras, instalación sencilla, fácil configuración, bajos
tiempos de respuesta, soporte para dos sistemas de bases de datos, y la posibilidad de
añadir nuevos controladores. Además, facilitaba el desarrollo del proyecto por la baja
curva de aprendizaje, al ser el autor del proyecto un colaborador en el diseño e
implementación del motor. Por otro lado, no existe en el mercado una amplia variedad
de motores de persistencia para PHP. Se puede consultar una lista de los motores de
persistencia disponibles para PHP en uno de los anexos.

• Smarty: es un motor de plantillas muy potente, versátil y rápido. Contiene una amplia
gama de funciones y permite añadir plugins. No existen otros que estén en un nivel
superior de madurez.

• phpDocumentor: ofrece una solución fácil y cómoda para la documentación

automática del software. Genera una gran variedad de estilos de documentación y
utiliza un formato muy parecido al de la documentación de Java.

• Eclipse: es un entorno de desarrollo, principalmente creado para Java, para el que

también existe un plugin para PHP. Está desarrollado en Java con lo que es
independiente de la plataforma y puede ser utilizado por los desarrolladores tanto en
Windows como Linux, y otros sistemas operativos. Otra de sus ventajas es que
contiene un cliente para CVS integrado con lo que se facilita mucho el trabajo
conjunto entre programadores, y la manejo de un programador de las conexiones con
el servidor de CVS.
14.Pruebas y resultados
Una de las principales incertidumbres durante la fase de análisis y diseño de la aplicación fue
la influencia del uso de frameworks, motor de persistencia y de plantillas en el tiempo de
respuesta de la aplicación. Es indudable que para aplicaciones de envergadura el uso de un
framework y un motor de persistencia no es una opción sino una necesidad, sobretodo si no se
quiere obtener una aplicación muy difícil de mantener y ampliar. En cambio, para el
desarrollo de pequeñas aplicaciones web cabía la posibilidad de que un incremento de la
reusabilidad, escalabilidad y en general del uso de patrones de diseño, aumentarían la carga de
proceso del software, lo que produciría un incremento en los tiempos de ejecución de los
scripts por encima de lo deseado. Existía, incluso, la posibilidad de que se pudiera llegar a un
nivel inviable por encima de los 5-10 segundos por petición de página. Esta incertidumbre se
vio engrandecida por la falta de información acerca de sistemas reales en funcionamiento con
PHP que utilizaran este tipo de software, algo que no sucede con tecnologías como Java,
donde suele ser bastante corriente el uso de este tipo de herramientas.

Antes de proceder a analizar los resultados en conveniente determinar cuales son los
parámetros de rendimiento que hemos analizado. Estos indicadores de la eficacia del
programa son básicamente dos: por un lado el tiempo de respuesta de una petición de página y
por otro el consumo de recursos (memoria y CPU) del script en el servidor.

En cuanto al tiempo de respuesta podemos definirlo como el tiempo total que trascurre desde
que el cliente web solicita una página hasta que se tiene totalmente cargada en el navegador.

Para los análisis hemos dividido este tiempo de respuesta en varias partes críticas de la
ejecución del script de la aplicación:

Tiempo respuesta = Consulta BD + Asignar variables plantilla + Resolver plantilla + Echo + Error

• Consulta DB: consulta a la base de datos.

• Asignar variables a la plantilla: consiste en indicar al motor de plantillas (Smarty)
cuales son los valores para las variables dinámicas en la petición de página.
• Resolver plantilla: tiempo que emplea el motor de plantillas en cargar los datos de la
petición en la plantilla de la página (contenido dinámico). Es aquí cuando se construye
el html de la página de respuesta.
 • Echo: llamada a la función echo de PHP para enviar la página html resultante al
navegador.
• Error: es el tiempo del script que no entra en ninguna de las anteriores partes críticas
que diferenciamos. Es un tiempo tan insignificante como para no ser tenido en cuenta.
Si llegará a ser muy alto es señal de que no estamos teniendo en cuenta alguna parte
del script que puede ser crítica.

Es necesario aclarar que la evaluación de la velocidad de respuesta de los scripts se ha he

hecho en un mismo ordenador en donde se encuentran tanto el servidor web como el
navegador. A los resultados obtenidos habría que añadir un incremento de tiempo para un
sistema real en producción, en el que el servidor web y el navegador son máquinas diferentes
que se comunican mediante una conexión de una determinada capacidad de transferencia
(módem, ADSL, etc.).

Distinguimos a efectos de análisis de rendimiento varios tipos de páginas que se dan en una
aplicación:

• Páginas estáticas: son páginas sencillas de información que solo contienen texto html
e imágenes y cuya información es fija o se obtiene de algún fichero de texto. En estas
páginas no se realizan consultas a la bases de datos.
• Páginas dinámicas: cuyo contenido está construido a partir de alguna acción
compleja que puede incluir una o varias consultas a bases de datos.

Todos los datos que se recogen de las pruebas están tomados con la ejecución de la aplicación
en un entorno con las siguientes condiciones de hardware y software:

Hardware:
• Procesador: AMD Athlon 64
• Memoria: 2 GB de RAM
• Disco duro: Seagate 169 GB a 7200 r.p.m.
Software:
• Sistema operativo: Windows XP
• Servidor web: Apache 1.3.12
• Versión PHP: 4.3.9.
 14.1.Páginas estáticas

Es responsabilidad del diseñador de software intentar utilizar estrategias que garanticen una
velocidad de ejecución de los scripts aceptable. Una de las estrategias usadas en este proyecto
es la caché de páginas que no tienen contenido dinámico. Mediante esta caché es posible
saltar la creación de la página la segunda vez que se llama y sucesivas, obteniéndola
directamente desde un fichero de texto en donde ha sido guardada después de ser solicitada
por primera vez. Esto evita el penalizar a las páginas estáticas con el tiempo requerido por el
motor de plantillas para generar las páginas dinámicas.

En la siguiente gráfica podemos ver los resultados para las páginas estáticas con y sin caché.
La mejora con el uso de la caché es muy significativa porque se ahorra el tiempo de montaje
de la página en el que se resuelve la plantilla.

Páginas estáticas: totales

0,450
0,400

0,350
Tiempo (sg)

0,300

0,250

0,200

0,150
0,100
Sin caché Con caché

Agradecimientos 0,429 0,112

Principal etnografía GC 0,282 0,115
Descargas 0,329 0,125
Inicio 0,231 0,120
Acerca de 0,367 0,128
Enlaces 0,345 0,124

A continuación vemos estos mismos datos desglosados según las distintas partes críticas del
tiempo de respuesta. De esta forma podemos saber a que parte del script está afectando
exactamente el uso de la caché de páginas. Como era de esperar el uso de la caché de páginas
evita tener que recurrir al motor de plantillas para construir la página, por lo tanto los tiempos
relacionados con las plantillas se han reducido hasta cero.
 Páginas estáticas: asignar variables a la plantilla

0,200

0,150

Tiempo (sg)
0,100

0,050

0,000
Sin caché Con caché

Agradecimientos 0,085 0,000

Principal etnografía GC 0,050 0,000
Descargas 0,061 0,000
Inicio 0,050 0,000
Acerca de 0,057 0,000
Enlaces 0,050 0,000

Páginas estáticas: resolver plantilla

0,200

0,150
Tiempo (sg)

0,100

0,050

0,000
Sin caché Con caché

Agradecimientos 0,184 0,000

Principal etnografía GC 0,058 0,000
Descargas 0,071 0,000
Inicio 0,044 0,000
Acerca de 0,138 0,000
Enlaces 0,136 0,000

Páginas estáticas: echo

0,200

0,150
Tiempo (sg)

0,100

0,050

0,000
Sin caché Con caché

Agradecimientos 0,000 0,000

Principal etnografía GC 0,000 0,000
Descargas 0,016 0,015
Inicio 0,000 0,000
Acerca de 0,010 0,015
Enlaces 0,012 0,014
 14.2.Páginas dinámicas
Las páginas dinámicas, para nuestro caso, son aquellas que obtienen los datos de una consulta
a la base de datos.

Los datos de las gráficas fueron obtenidos de la página de la aplicación que muestra el listado
de bienes etnográficos. Esta página permite indicar al usuario el número de registros que
quiere mostrar a la vez (paginación).

Primero se hizo un análisis para un número de registros de funcionamiento normal de la

aplicación (10 a 150), y luego se llevó la aplicación al límite para comprobar su
funcionamiento en casos extremos (500 a 6000 registros).

En la siguiente gráfica podemos ver cuales son las partes del script que se ven más afectadas
por el incremento en el número de registros, o lo que es lo mismo, que partes del script son las
que contribuyen a que aumente el tiempo de respuesta cuando se incrementa el número de
registros.

Partes del script que dependen del número de registros

5,097
5
4,845
4,724
4,630
4,540 4,475
4,380
4,285 4,237 4,288
4 3,979 3,970
3,691

3,365 3,445 3,388

3,127 3,154
3 2,924 2,951
2,879
Tiempo (sg)

2,597
2,706 2,638 2,672 2,733
2,467
2,295 2,360 2,311

2 2,055
1,963 1,884 1,939
1,652 1,655
1,414 1,476 1,426 1,456
1,174 1,111
1
0,764 0,819
0,692 0,705
0,585 0,550 0,549
0,437
0,316 0,319 0,360
0,170 0,192 0,237 0,243
0,092 0,098 0,096
0
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150

Resolver plantilla 0,316 0,585 0,764 1,111 1,426 1,456 1,655 1,939 2,924 2,311 2,672 2,733 2,951 3,154 3,388
Echo 0,092 0,098 0,096 0,170 0,192 0,237 0,243 0,437 0,319 0,360 0,550 0,819 0,692 0,549 0,705
Suma de parciales 1,174 1,476 1,652 2,055 2,360 2,467 2,638 3,127 3,979 3,445 3,970 4,288 4,380 4,475 4,845
T otal 1,414 1,963 1,884 2,295 2,597 2,706 2,879 3,365 4,285 3,691 4,237 4,540 4,630 4,724 5,097
La suma de parciales es la suma de todos los tiempos críticos en que hemos dividido el script
para calcular el tiempo de respuesta, y el total indica el tiempo total del script. La diferencia
entre ambos nos da una medida de la eficacia en la selección de las partes críticas, es decir,
nos indica si hemos dejado atrás alguna parte crítica o no. Como se puede ver en la gráfica la
diferencia entre ambos es constante por lo que no hemos dejado atrás ninguna parte crítica por
medir del script. La pequeña diferencia que hay entre el tiempo total y la suma de parciales
representa los tiempos de las acciones que se llevan a cabo siempre y que son constantes
como la gestión de la sesión, inicialización de la aplicación, etc.

De esta gráfica podemos deducir que el resolver la plantilla (motor de persistencia) y enviarla
al navegador (echo) son las partes que más aumentan, lo cual parece lógico, teniendo en
cuenta que la plantilla tendrá más registros y que la página tardará más en ser enviada debido
a su mayor tamaño.

En la siguiente gráfica, por el contrario, vemos como la consulta a la base de datos y la

entrega al motor de plantillas del contenido de la página, no dependen del número de
registros.

Partes del script que no dependen del número de registros

5,097
5
4,845
4,724
4,630
4,540 4,475
4,380
4,285 4,237 4,288
4 3,979 3,970
3,691
3,365 3,445
3,127
3
2,879
Tiempo (sg)

2,706 2,638
2,597
2,467
2,295 2,360
2 2,055
1,963 1,884
1,652
1,414 1,476
1,174
1

0,634 0,645 0,658 0,625 0,595 0,633 0,600 0,600 0,597 0,638 0,598 0,598 0,599 0,631
0 ,598

0,132 0,148 0,134 0,149 0,147 0,141 0,140 0,151 0,139 0,136 0,150 0,138 0,138 0,141
0 ,154
0
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150

Consulta a la base de datos 0,634 0,645 0,658 0,625 0,595 0,633 0,600 0,600 0,597 0,638 0,598 0,598 0,599 0,631 0,598
Asignar variables a plantilla 0,132 0,148 0,134 0,149 0,147 0,141 0,140 0,151 0,139 0,136 0,150 0,138 0,138 0,141 0,154
Suma de parciales 1,174 1,476 1,652 2,055 2,360 2,467 2,638 3,127 3,979 3,445 3,970 4,288 4,380 4,475 4,845
T otal 1,414 1,963 1,884 2,295 2,597 2,706 2,879 3,365 4,285 3,691 4,237 4,540 4,630 4,724 5,097
Para peticiones con un gran número de registros el script se comporta igual que para los casos
que ya hemos visto, es decir, se mantiene una relación lineal entre el número de registros
solicitados y el tiempo de respuesta.

Partes del script que dependen del número de registros

200

150
Tiempo (sg)

100

50

0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Resolver plantilla 12,500 22,670 37,230 48,410 72,580 118,700 89,110 103,300 119,500 134,500 152,500 168,600
Echo 2,133 4,112 6,191 8,218 10,510 13,570 17,010 20,340 24,390 28,370 31,060 35,540
Suma de parciales 15,364 27,559 44,168 57,427 83,868 133,091 106,954 124,493 144,810 163,798 184,472 205,043
T otal 15,680 27,970 44,680 58,020 84,550 133,900 107,080 125,500 145,900 164,900 185,700 206,300
 Partes del script que no dependen del número de registros

1,000

0,664 0,657
0,625 0,631 0,629 0,624 0,625 0,625 0,625
0,595 0,594 0,595
Tiempo (sg)

0,500

0,287 0,278
0,271
0,256
0,228
0,210
0,183 0,192
0,168
0,152 0,153
0,136

0,000
500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Consulta a la base de datos 0,595 0,625 0,594 0,631 0,595 0,629 0,624 0,625 0,664 0,657 0,625 0,625
Asignar variables a plantilla 0,136 0,152 0,153 0,168 0,183 0,192 0,210 0,228 0,256 0,271 0,287 0,278
Suma de parciales 15,364 27,559 44,168 57,427 83,868 133,091 106,954 124,493 144,810 163,798 184,472 205,043
T otal 15,680 27,970 44,680 58,020 84,550 133,900 107,080 125,500 145,900 164,900 185,700 206,300

A partir de estas gráficas podemos obtener la conclusión de que los principales tiempos a
tener en cuenta para reducir el tiempo de respuesta de la aplicación son: el tiempo que tarda el
motor de plantillas en resolver la plantilla y el tiempo que se tarda en enviar al cliente. Y que
en este caso concreto el primero es de mayor coeficiente que el segundo, aunque
probablemente el segundo se vea muy significativamente aumentado en un entorno de
producción donde la conexión con el navegador no es directa.

Por lo tanto para mejorar estos tiempos caben varias acciones como son: probar con otro
motor de plantillas, reducir el tamaño de las páginas para que se envíen más rápidamente, y/o
reducir el tiempo que tarda el motor de plantillas en resolver un registro de la plantilla.

Una duda que puede aparecer a la vista de la gráfica es por qué se produce un pico entorno a
los 3000 registros. La razón es que las pruebas se hicieron con datos reales, por lo tanto el
tamaño de los registros varía. Entorno a los 3000 registros coincide que están los registros del
municipio de Las Palmas de Gran Canaria cuyo nombre es sensiblemente mayor al del resto
de los municipios, esto hace que los registros ocupen un poco más, lo que provoca que se
incrementen los tiempos.
Los tiempos calculados hasta ahora hacen referencia a una sola petición de página. En un
contexto de producción real en el que la aplicación esté dando servicios a múltiples usuarios,
lo normal es que se produzcan, o al menos pueden producirse, varias peticiones simultáneas.

La siguiente gráfica muestra el tiempo de respuesta para distintos anchos de banda de

conexión entre el servidor web y el cliente web. Se ha fijado el tamaño de página a 200KB y
se ha supuesto que el incremento en tiempo de CPU para cada script es proporcional al
número de peticiones simultáneas. De esta gráfica se obtiene la conclusión de que la inversión
mínima ideal en ancho de banda debe ser aquella que produzca un tiempo de respuesta total
equivalente al tiempo de CPU, o lo que es lo mismo, que los clientes no tengan que esperar
por la transferencia de la página más de lo que tarda el servidor en crearla. Para nuestro caso,
suponiendo que tenemos siempre como máximo 2 peticiones simultáneas y queremos
mantener el tiempo de respuesta por debajo de los 10 segundos tendremos que tener un ancho
de banda desde el servidor web hacia el cliente de cómo mínimo 64KB.
Por último en cuanto al consumo de memoria es importante calcular la cantidad de memoria
necesaria. Para el caso concreto de este análisis, cada script PHP utilizó unos 30 MB de
memoria más otros 3 MB del proceso de Postgres que gestiona la consulta a la base de datos.
En total se requieren unos 33 MB por petición. Indudablemente cuando aumenta el número de
peticiones concurrentes aumenta las necesidades de memoria, llegando un punto en el que la
paginación (mover bloques de memoria al disco) puede provocar un incremento de los
tiempos. La situación ideal sería calcular cuantos procesos de PHP se ejecutan paralelamente
y garantizar que exista memoria suficiente para que no se produzca la paginación. Si el
número de procesos es demasiado elevado y no podemos evitar la paginación debido al límite
en la cantidad de memoria que se le puede instalar al servidor, entonces, si no queremos
renunciar a los tiempos de respuestas, deberemos de acudir a algún tipo de estrategia de
balanceo de carga en la que se usen varios servidores web distintos (máquinas distintas) en
donde esté instalada la aplicación, y que se repartan las peticiones.
15.Documentación
Una parte importante en el desarrollo del software es la documentación. Una documentación
profusa y extendida es primordial para el buen mantenimiento del software a lo largo de su
periodo de vida.
En este caso la documentación del código se ha realizado con phpDocumentor. Se trata de una
herramienta para la autodocumentación de código similar a JavaDoc para Java. El
programador es el responsable de comentar cada una de las funciones y en general todo el
código que escribe. Mediante phpDocumentor, que puede ser usado con la interfaz web o
desde la línea de comandos, se genera la documentación del código. Permite generar varios
tipos de formatos entre los que destacamos: html, pdf, ayuda chm de Windows ó XML.

La documentación se lleva a cabo mediante el uso de tags o etiquetas. Un ejemplo de función

comentada podría ser:

/**
* Descripción corta.
*
* Descripción larga.
*
* @access public or private
* @author nombre <nombre@email>
* @param tipo nombre descripción
* @return tipo descripción
*/
function ejemploDocumentacion($nombre) { ; }

Existe una lista predefinida de tags pero se pueden añadir todos los que se deseen. Este tipo de
herramientas facilita mucho el mantenimiento del código por parte de los desarrolladores y la
integración de nuevos programadores en un proyecto.
16.Implantación del sistema

16.1.Requisitos para la instalación.

Para la implantación del sistema son necesarios los siguientes requisitos:

1. Disponer de un servidor web conectado a Internet.

2. PHP 4.3.9 o superior e inferior a PHP 5 (la aplicación no está testeada para PHP 5
porque en el momento de la implementación del código solo existía una versión beta).

3. Modulo Oci8 de PHP para el acceso a bases de datos de Oracle si se va a usar el driver
de Oracle del motor de Persistencia. También es necesario que la variable
NLS_LANG de entorno del sistema operativo (Linux) esté establecida al idioma local
donde se instala la aplicación.

4. Conexión al servidor con una tasa de transferencia de cómo mínimo 512 Kb por parte
del cliente, y en cuanto al servidor debería disponer de una conexión de 2 Mb como
mínimo, dependiendo del número de usuarios conectados simultáneamente.

5. Servidor de bases de datos con PostgreSQL. Puede ser el mismo que el servidor web.
El motor de persistencia incluye también driver para Oracle.

6. Bases de datos creadas, para ello la aplicación contiene los scripts con las sentencias
SQL que generan las bases de datos.

16.2.Instalación
La instalación es tan sencilla como copiar la aplicación al directorio público del servidor web.
La aplicación autodetecta el sistema operativo y la ruta en donde se encuentra. El directorio
config contiene los ficheros de configuración de la aplicación. El único fichero que es
indispensable configurar es el DBServers-config.xml que contiene la lista de servidores de
bases de datos. Los ficheros de configuración de la aplicación son los siguientes:

• AppConfig.php: contiene las rutas de los distintos directorios que usa la aplicación.
• Domain-config.php: contiene información de configuración del dominio de la
aplicación.

• ExternalPaths.php: clase que se utiliza para la inclusión en PHP de las rutas de los
ficheros de la aplicación que son de desarrollo externo, como las librerías de código.
Estas pueden estar ubicadas en cualquier sitio (ruta).

• GlobalPaths.php: clase que se usa para la inclusión de las rutas de los ficheros de la
aplicación que son de desarrollo externo pero que se incluyen en el mismo directorio
principal de la aplicación. De esta forma se evita que el usuario tenga que obtener e
instalar estos módulos.

• Globals.php: variables globales de la aplicación.

• ModulePaths.php: clase que se usa para la inclusión de las rutas de los ficheros
propios de la aplicación.

• PrQDBMapping.php: fichero de correspondencias del motor de persistencia. Se

utiliza para relacionar las tablas y campos que usa la aplicación con sus
correspondientes en el sistema de bases de datos concreto.

• Web.php: es el equivalente a web.xml de J2EE. Se trata del fichero de despliegue de

la aplicación en donde se pueden especificar parámetros de configuración de misma.

• Actions-config.xml: fichero con información de configuración de las acciones de la

aplicación.

• DBServers-config.xml: fichero de configuración de los servidores de bases de datos.

Incluye un listado con los servidores disponibles, su nombre, puerto de conexión, tipo
de base de datos, etc.

• phpmvc-config.xml: fichero de configuración para phpMVC. En este fichero se

indican las acciones, formularios, controladores, etc. que contiene la aplicación.
 16.3.Implantación
Al tratarse de una aplicación web, el grado de resistencia o dificultad para usuarios que
consultan la información es mínimo. Cualquier persona que use ó haya usado Internet en
algún momento será capaz de obtener del sistema lo que desee. En cambio, para los usuarios
técnicos que se encargarían del mantenimiento de los datos puede darse un periodo de
adaptación a este nuevo tipo de Interfaz. En general los usuarios no informáticos de
aplicaciones de gestión están familiarizados o acostumbrados al uso de aplicaciones locales,
cuyas interfaces suelen tener un alto grado de prestaciones, un diseño amigable y un tiempo
de respuesta sensiblemente menor al de una aplicación web. Para este tipo de usuarios la
aplicación podría parecer lenta o incluso incómoda de usar. En estos casos se requeriría de un
periodo mínimo de adaptación. Sería aconsejable una disminución de esta desventaja en
cuanto a su implantación, proporcionando a este tipo de usuarios unas mayores velocidades de
conexión e integrando nuevas herramientas y métodos de navegación a la aplicación según
sus necesidades, para intentar minimizar de esta manera la diferencia entre este tipo de
aplicaciones y las de carácter local.

16.4.Mantenimiento
Se pueden diferenciar dos tipos de mantenimiento que demanda la aplicación: por un lado el
mantenimiento del software que consiste básicamente en la corrección de los errores que
puedan aparecer y la implantación de nuevas mejoras, y por otro lado, el mantenimiento del
servidor, que incluye contar con un servidor web activo las 24 horas y una conexión de banda
ancha.

16.5.Costes de explotación
Los costes de explotación se derivan del mantenimiento de la aplicación.

En cuanto a los costes en hardware dependerán del tipo de servidor web en que se instale. Se
puede optar por el alquiler de hosting de un servidor o montar uno propio. Ambas soluciones
tienen ventajas e inconvenientes. Si se opta por la opción de alquilar los servicios de hosting,
se puede obtener un precio razonable sin la necesidad de tener que llevar el mantenimiento del
host. Por otro lado, también se ahorra en el contrato de conexión para la banda ancha. Por el
contrario, se tiene limitada la cantidad de servicios de que se dispone, como por ejemplo, las
actualizaciones del lenguaje de programación, la incorporación de nuevos lenguajes, la
cantidad de sistemas de bases de datos que soportan, etc. Además, las actualizaciones de la
aplicación son más complicadas.
En cuanto a los costes de software, estos dependerán del número de ampliaciones que se
quieran llevar a cabo y del tipo de las mismas. Podría ser conveniente la contratación de un
servicio de mantenimiento de la aplicación, para realizar diversas tareas como copias de
seguridad de los datos, actualizaciones de las páginas, etc.

En la siguiente tabla podemos ver un resumen de los costes.

Concepto Coste

Hardware

Servidor propio. 1.500 - 15.000 Euros

Dependerá del número de conexiones simultáneas.

Contratación hosting servidor dedicado. Depende del mercado.

Redes/comunicación

ADSL para el mantenimiento de la página. 30 Euros \ mes

DSL servidor web. Depende del mercado.

Software

Ampliaciones y mejoras.

A presupuestar en cada caso.

R.R.H.H.

Personal para mantenimiento del servidor y aplicación. 200 - 1.500 Euros \ mes

Dependerá del número de actualizaciones y tareas de

mantenimiento.
17.Conclusiones
La principal motivación para abordar este proyecto fue la investigación en el ámbito de las
aplicaciones web, y más concretamente en el uso de frameworks que permitan desarrollar un
software de alta calidad. Se trata de un campo de la informática que se ha visto desbordado
por la necesidad de un crecimiento vertiginoso. Frecuentemente, este tipo de aplicaciones se
demandan a bajos costes de producción y en cortísimos tiempos de desarrollo, y son llevadas
a cabo por especialistas en diseño, o por personas que no tiene una visión global técnica de lo
que es la generación de software. Esta situación había producido hasta el momento un
detrimento en el uso de técnicas de ingeniería del software en favor de la implementación
directa lo cual desemboca en la creación de un software poco reutilizable y difícil de
mantener. Hoy en día esta cambiando el contexto, y cada vez más, vemos como el mercado
demanda aplicaciones más complejas que en principio estaban reservadas a unas pocas
aplicaciones de gestión, como por ejemplo las de gestión bancaria. Por lo tanto, existe un
amplio grupo de aplicaciones de tamaño medio que precisan de un coste medio de
producción, pero de unas prestaciones también medias en cuanto a su escalabilidad y
complejidad.

Este proyecto viene a confirmar que es posible la generación de aplicaciones web basadas en
métodos de ingeniería del software que produzcan aplicaciones robustas y fiables, capaces de
ser ampliadas, y que gestionen procesos complejos, y que a pesar de todo ello tengan unos
costes de producción razonables. Por esto es importante la elección por la que se optó en este
proyecto en cuanto a la selección de herramientas gratuitas, que no por ello menos fiables o
potentes.

En resumen, podemos decir, que no solamente es posible el desarrollo de aplicaciones

complejas, estructuradas y perfectamente orientadas a objetos en PHP, sino que se consigue
de una forma eficiente, rápida y económica. Esta fue una de las principales conclusiones que
se obtuvieron en este proyecto.

Otra de las conclusiones a las que se llegó y que está relacionada muy íntimamente con la
primera, es que es posible el uso de una metodología de ingeniería del software para
aplicaciones web sin que ello vaya en un aumento en el coste del producto. Existe una especie
de regla no oficial, según la cual para proyectos pequeños o medianos los costes que puedan
derivarse del uso de una metodología de ingeniería del software no son proporcionales a los
beneficios que puedan derivarse de su uso, ya que en la mayoría de los casos se trata de
proyectos que no se ampliarán o que están limitados en presupuesto. Este tipo de metodología
exige un esfuerzo en primer momento mayor al que se requeriría en la implementación directa
(o con un análisis más breve) de la aplicación, y provoca un aumento en horas de
programación y en los tiempos de ejecución de los scripts. Pues bien, este proyecto demuestra
que es posible generar aplicaciones pequeñas o medianas completamente compatibles con el
uso de técnicas y métodos de ingeniería, con un pequeño incremento en el tiempo de
ejecución y programación (y por lo tanto de coste) admisible. Solamente hay que tener en
cuenta que se debe usar un enfoque ingenieril que no parta de un diseño de la solución desde
cero, sino mediante la integración de herramientas ya disponibles en el mercado. El 50% del
trabajo del ingeniero que se dedique al diseño de aplicaciones web hoy en día, no consiste en
aportar soluciones a sus análisis, sino más bien, en elegir las soluciones ya existentes e
integrarlas en una nueva aplicación.

Para finalizar se puede afirmar que la conclusión más relevante que se obtiene es que es
posible desarrollar aplicaciones web en PHP mediante frameworks de forma eficiente y
eficaz.
18.Trabajo futuro
El presente proyecto se puede ampliar en dos principales direcciones, a saber, por un lado en
la incorporación de mejoras de rendimiento a las capacidades que ya posee y, por otro lado, a
la ampliación de su funcionalidad.

En cuanto a las posibles mejoras podemos citar la creación de algún tipo de caché de dominio
que almacene los objetos obtenidos de la base de datos. De esta forma se podría disminuir el
tiempo de respuesta para las páginas que necesitan una consulta a la base de datos. En la
mayoría de los casos una consulta suele ser costosa, y a esto podemos añadir que el servidor
de la base de datos puede encontrarse en una máquina alejada físicamente del servidor web,
y/o con un ancho de banda de conexión bajo. El principal inconveniente para esta mejora es
la dificultad de garantizar que no se ofrezcan datos desfasados e incorrectos con respecto a los
originales, y que se produzcan todas las actualizaciones correctamente, y en definitiva, todos
los inconvenientes derivados de que sea la aplicación la encargada de gestionar los problemas
de concurrencia, el lugar de solamente el sistema de base de datos.

En cuanto a las ampliaciones en funcionalidad, podrían incluirse el resto de herramientas que

contempla la ley para la gestión de los bienes culturales como son los catálogos y cartas
municipales, así como los registros e inventarios regionales. También sería bastante útil la
incorporación de un buscador global en todas las bases de datos, para poder buscar una
cadena o conjunto de palabras al estilo de los buscadores de Internet, o de forma un poco más
avanzada, permitiendo seleccionar la zona y el tipo de bien.
19.Bibliografía y referencias
[MCU] Ministerio de Cultura
Leyes de Patrimonio
http://www.mcu.es/

[ALV92] José Luís Álvarez.

Sociedad, Estado y Patrimonio Cultural
1992 Espasa-Calpe

[LUG88] Félix Benítez de Lugo y Guillén

El Patrimonio Cultural Español (Aspectos jurídicos, administrativos y fiscales)
1988 Comares

[PRESS02] Roger S. Pressman

Ingeniería del Software (Un enfoque práctico)
2002 McGraw Hill

[LAR99] Craig Larman

UML y patrones (Introducción al análisis y diseño orientado a objetos)
1999 Pentice Hall

[WIK] Wikipedia
Enciclopedia libre
http://es.wikipedia.org/

[AUM02] Benjamin Aumaille

J2EE Desarrollo de aplicaciones Web
Eni ediciones

[STRUTS] Struts
http://struts.apache.org/

[phpMVC] phpMVC
http://www.phpmvc.net/
[Ambler00] Scott W. Ambler
The Design of Robust Persistence Layer for Relational Databases
http://www.ambysoft.com/essays/persistenceLayer.html

[phpDoc] phpDocumentor
http://www.phpdoc.org/

[phpMVCframe] Listado de frameworks MVC para PHP

http://www.phpwact.org/php/mvc_frameworks
I. ANEXO. Modelo de datos de inventarios insulares del sistema
actual

I.1. Ficha de bien etnográfico

TABLA BIC_ETNOGRAFICO
ESTRUCTURA
DATOS GENERALES
Datos principales
Campo Tipo Etiqueta español
COD_FICHA Autonumérico Código
NUMERO Texto Código D.G.P.
DENOMINACION Texto Nombre
ISLA Texto Isla
MUNICIPIO Texto Municipio
LOCALIDAD Texto Localidad
ACTIVIDAD Texto Actividad
GRUPO Texto Grupo
TIPO Texto Tipo
NOMBRE_FOTO Texto Nombre foto
NOMBRE_CROQUIS Texto Nombre croquis
PATRIMONIO ETNOGRÁFICO
Localización
Campo Tipo Etiqueta español
CALLE Texto Calle
NUMERO_CALLE Texto Nº/Piso
COD_POSTAL Numérico Código postal
TELEFONO Texto Teléfono
UTM_CUADRANTE Numérico UTM
X Numérico X
Y Numérico Y
ALTITUD Numérico Altitud
CARTOGRAFIA Texto Cartografía
TOPONIMIAS Texto Toponimias
OBS_LOCALIZACION Memo Observaciones localización
Datos asociados al bien etnográfico
Campo Tipo Etiqueta español
FECHA_CONSTRUCCION Texto Fecha construcción
ANTIGUEDAD Texto Antigüedad
USO_ACTUAL Texto Uso actual
SUPERFICIE Numérico Superficie
HISTORIA Memo Historia
DESCRIPCION Memo Descripción
CONSERVACIÓN Y DOCUMENTACIÓN
Estados de conservación
Campo Tipo Etiqueta español
Alteraciones antrópicas
DEST_OBRAS Sí/No Destrucción por obras públicas
SAQUEOS Sí/No Saqueos
OTRAS Sí/No Otras
Alteraciones naturales
ALTE_NATURALES Sí/No Alteraciones naturales
Observaciones de estado
OBS_ESTADO Memo Observaciones
Documentación
Campo Tipo Etiqueta español
DOCUMENTACION Memo Documentación
ESTADO Texto Estado de conservación
FRAGILIDAD Texto Fragilidad
VALOR_CIENTIFICO Texto Valor científico patrimonial
JURÍDICO-ADMINISTRATIVA-PERSONAL
Situación jurídico-administrativa
Campo Tipo Etiqueta español
PROPIEDAD Texto Propiedad
DECLARACION_BIC Sí/No Declaración B.I.C.
FECHA_INCOACION Fecha/Hora Fecha incoación
FECHA_DECLARACION Fecha/Hora Fecha declaración
CLASIFICACION_SUELO Texto Clasificación del suelo
CALIFICACION_SUELO Texto Calificación del suelo
CATALOGO Texto Catálogo municipal
INTERVENCIONES Memo Tipo de intervención
NIVEL_PROTECCION Numérico Nivel de protección
GRADO_PROTECCION Texto Grado de protección

SUGERENCIAS Memo Sugerencias

OBS_GENERALES
Memo Observaciones

PERSONAS ASOCIADAS
Campo Tipo Etiqueta español
Propietario
NOMBRE_PROPIETARIO Texto Nombre
DNI_PROPIETARIO Texto D.N.I.
TELEFONO_PROPIETARIO Texto Teléfono
DIRECCION_PROPIETARIO Texto Dirección
Representante
NOMBRE_REPRESENTANTE Texto Nombre
DNI_REPRESENTANTE Texto D.N.I.
TELEFONO_REPRESENTANTE Texto Teléfono
DIRECCION_REPRESENTANTE Texto Dirección
Guardián
NOMBRE_GUARDIAN Texto Nombre
DNI_GUARDIAN Texto D.N.I.
TELEFONO_GUARDIAN Texto Teléfono
DIRECCION_GUARDIAN Texto Dirección
Usuario
NOMBRE_USUARIO Texto Nombre
DNI_USUARIO Texto D.N.I.
TELEFONO_USUARIO Texto Teléfono
DIRECCION_USUARIO Texto Dirección
 I.2. Ficha de bien arqueológico
TABLA BIC_ARQUEOLOGICO
ESTRUCTURA
DATOS GENERALES
Datos principales
Campo Tipo Etiqueta español
COD_FICHA Numérico Código ficha
DENOMINACION Texto Denominación
Datos de la propiedad
PROPIEDAD Texto Propiedad
USO_ACTUAL Texto Uso actual
NOMBRE_PROPIETARIO Texto Nombre propietario
DIRECCION_PROPIETARIO Texto Dirección propietario
C_POSTAL_PROPIETARIO Texto Código postal propietario
LOCALIDAD_PROPIETARIO Texto Localidad propietario
TELEFONO_PROPIETARIO Texto Teléfono propietario
CLASIFICACION_SUELO Texto Clasificación del suelo
CALIFICACION_SUELO Texto Calificación del suelo
DECLARACION_BIC Sí/No Declaración B.I.C.
FECHA_INCOACION Fecha/Hora Fecha incoación
FECHA_DECLARACION Fecha/Hora Fecha declaración
NOMBRE_FOTO Texto Nombre foto
LOCALIZACIÓN
Campo Tipo Etiqueta español
ISLA Texto Isla
MUNICIPIO Texto Municipio
LOCALIDAD Texto Localidad
TOPONIMIAS Texto Toponimias
CARTOGRAFIA Texto Cartografía
ACCESO Memo Acceso
UTM_CUADRANTE Numérico UTM
X Numérico X
Y Numérico Y
ALTITUD Numérico Altitud
PENDIENTE Texto Pendiente
EXPOSICION Texto Exposición
PISO_BIOCLIMATICO Texto Piso bioclimático
SUSTRATO Texto Sustrato
UNIDAD_GEOMORFOLOGICA Texto Unidad geomorfológica
NOMBRE_MAPA Texto Nombre mapa
ESCALA Texto Escala
TIPOLOGÍA
Campo Tipo Etiqueta español
TTIPO Texto Tipología
TECONOMICO Texto Tipo económico
TFUNERARIO Texto Tipo funerario
THABITAT Texto Tipo hábitat
TCULTUAL Texto Tipo cultual
TARTE Texto Tipo arte
TOTROS Texto Tipo otros
Económico
Campo Tipo Etiqueta español
GRANERO Numérico Granero
GAMBUESA Numérico Gambuesa
CANTERA Numérico Cantera
SILO Numérico Silo
CONCHERO Numérico Conchero
TALLER Numérico Taller
OTROS_ECONOMICO Texto Otra tipología económica
OBS_ECONOMICO Texto Observaciones tipología económica
Funerario
Campo Tipo Etiqueta español
CUEVA_NATURAL_F Numérico Cueva natural
CUEVA_ARTIFICIAL_F Numérico Cueva artificial
SOLAPON Numérico Solapón
TUMULO Numérico Túmulo
CISTA Numérico Cista
OTROS_FUNERARIO Texto Otra tipología funeraria
OBS_FUNERARIO Texto Observaciones tipología funeraria
Hábitat
Campo Tipo Etiqueta español
CUEVA_NATURAL_H Numérico Cueva natural
CUEVA_ARTIFICIAL_H Numérico Cueva artificial
CASAS Numérico Casas
REFUGIO Numérico Refugio
OTROS_HABITAT Texto Otra tipología hábitat
OBS_HABITAT Texto Observaciones tipología hábitat
Cultual
Campo Tipo Etiqueta español
ALMOGAREN Numérico Almogarén
CAZOLETAS Numérico Cazoletas
CIR_PIEDRA Numérico Círculos de piedra
TORRETAS Numérico Torretas
OTROS_CULTUAL Texto Otra tipología cultual
OBS_CULTUAL Texto Observaciones tipología cultual
Manifestaciones rupestres
Campo Tipo Etiqueta español
Grabados
GEOMETRICOS Numérico Geométricos
ALFABETIFORMES Numérico Alfabetiformes
ZOOMORFOS Numérico Zoomorfos
ANTROPOMORFOS Numérico Antropomorfos
OTROS_GRABADOS Texto Otros grabados
Pinturas
ANTROPOMORFAS Numérico Antropomorfas
ZOCALOS Numérico Zócalos
GEOMETRICAS Numérico Pinturas geométricas
OTROS_PINTURAS Texto Otras pinturas

OBS_RUPESTRE Texto Observaciones manifestaciones rupestres

Otras construcciones
Campo Tipo Etiqueta español
PIEDRAS_HINCADAS Numérico Piedras hincadas
MURALLA Numérico Muralla
HIDRAULICO Numérico Hidráulico
MUROS Numérico Muros
OTROS_CONSTRUCCIONES Texto Otras construcciones
OBS_CONSTRUCCIONES Texto Observaciones construcciones
Ergología
ERGOLOGIA Memo Ergología
CONSERVACIÓN
Alteraciones y grados de afección
Campo Tipo Etiqueta español
DESPRENDIMIENTOS Texto Desprendimientos
CAIDA_MUROS Texto Caída de muros
VERTIDO_ESCOMBROS Texto Vertido de escombros
BASUSRAS_DISPERSAS Texto Basuras dispersas
RESIDUOS_FECALES Texto Residuos fecales
RESIDUOS_LIQUIDOS Texto Residuos líquidos
DIBUJOS_ACTUALES Texto Dibujos actuales
EROSION_SEDIMENTACION Texto Erosión/Sedimentación
RECOLONIZACION_VEGETAL Texto Recolonización vegetal
OTROS_VALORES Texto Otras alteraciones
OBS_GENERALES Memo Observaciones conservación
Datos de uso y reutilización
Reutilización
Campo Tipo Etiqueta español
REUTILIZACION Sí/No Reutilización
Uso
Campo Tipo Etiqueta español
HABITAT Sí/No Hábitat
GANADERO Sí/No Ganadero
AGRICOLA Sí/No Agrícola
BASURERO Sí/No Basurero
OTROS_USOS Texto Otros usos
OBSERVACIONES
Documentación y observaciones
Campo Tipo Etiqueta español
BIBLIOGRAFIA Memo Bibliografía
INVESTIGACIONES Memo Investigaciones
SUGERENCIAS Memo Sugerencias
OBS_GENERALES Memo Observaciones generales
 I.3. Ficha de bien arquitectónico
TABLA BIC_ARQUITECTONICO
ESTRUCTURA
DATOS GENERALES
Datos principales
Campo Tipo Etiqueta español
COD_FICHA Numérico Código ficha
DENOMINACION Texto Denominación
Datos de la propiedad
Campo Tipo Etiqueta español
PROPIEDAD Texto Propiedad
USO_ORIGINAL Texto Uso original
USO_ACTUAL Texto Uso actual
ORDENANZA Sí/No Ordenanza
CLASIFICACION_SUELO Texto Clasificación del suelo
CALIFICACION_SUELO Texto Calificación del suelo
NOMBRE_PROPIETARIO Texto Nombre propietario
DIRECCION_PROPIETARIO Texto Dirección propietario
LOCALIDAD_PROPIETARIO Texto Localidad propietario
C_POSTAL_PROPIETARIO Texto Código postal propietario
TELEFONO_PROPIETARIO Texto Teléfono propietario
NOMBRE_FOTO Texto Nombre foto
Fotografía
Campo Tipo Etiqueta español
NOMBRE_FOTO Texto Nombre imagen
LOCALIZACIÓN
Localización
Campo Tipo Etiqueta español
ISLA Texto Isla
MUNICIPIO Texto Municipio
LOCALIDAD Texto Localidad
TOPONIMIAS Texto Toponimias
CARTOGRAFIA Texto Cartografía
DIRECCION Texto Dirección
REF_CATASTRAL Texto Referencia catastral
SUPERFICIE Numérico Superficie construida (m2)
UTM_CUADRANTE Numérico UTM
X Numérico X
Y Numérico Y
Z Numérico Z
Mapa
NOMBRE_MAPA Texto Nombre mapa
ESCALA Texto Escala
TIPOLOGÍA
Tipología
Campo Tipo Etiqueta español
SIGLO Texto Siglo
CRONOLOGIA Texto Cronología
TIPOLOGIA Texto Tipología
Planos
Campo Tipo Etiqueta español
NOMBRE_PLANO Texto Nombre plano
INTERIOR
Campo Tipo Etiqueta español
CIMIENTOS_MAT Texto Materiales cimientos
CIMIENTOS_EST Texto Estado cimientos
CIMIENTOS_ACT Texto Actuaciones cimientos
FORJADOS_MAT Texto Materiales estructuras horizontales
FORJADOS_EST Texto Estado estructuras horizontales
FORJADOS_ACT Texto Actuaciones estructuras horizontales
ESTRUCTURA_MAT Texto Materiales estructuras verticales
ESTRUCTURA_EST Texto Estado estructuras verticales
ESTRUCTURA_ACT Texto Actuaciones estructuras verticales
EXTERIOR
Campo Tipo Etiqueta español
FACHADA_MAT Texto Materiales fachadas
FACHADA_EST Texto Estado fachadas
FACHADA_ACT Texto Actuaciones fachadas
REVESTIMIENTO_MAT Texto Materiales revestimiento
REVESTIMIENTO_EST Texto Estado revestimiento
REVESTIMIENTO_ACT Texto Actuaciones revestimiento
CARPINTERIA_MAT Texto Materiales carpinterías
CARPINTERIA_EST Texto Estado carpinterías
CARPINTERIA_ACT Texto Actuaciones carpinterías
DINTELES_MAT Texto Materiales dinteles, jambas y alféizar
DINTELES_EST Texto Estado dinteles, jambas y alféizar
DINTELES_ACT Texto Actuaciones dinteles, jambas y alféizar
BALCONES_MAT Texto Materiales balcones
BALCONES_EST Texto Estado balcones
BALCONES_ACT Texto Actuaciones balcones
ZOCALOS_MAT Texto Materiales zócalos
ZOCALOS_EST Texto Estado zócalos
ZOCALOS_ACT Texto Actuaciones zócalos
CORNISA_MAT Texto Materiales cornisas
CORNISA_EST Texto Estado cornisas
CORNISA_ACT Texto Actuaciones cornisas
DECORATIVOS_MAT Texto Materiales elementos decorativos
DECORATIVOS_EST Texto Estado elementos decorativos
DECORATIVOS_ACT Texto Actuaciones elementos decorativos
COLOR_MAT Texto Materiales color
COLOR_EST Texto Estado color
COLOR_ACT Texto Actuaciones color
ZAGUAN_MAT Texto Materiales zaguán
ZAGUAN_EST Texto Estado zaguán
ZAGUAN_ACT Texto Actuaciones zaguán
ESCALERAS_MAT Texto Materiales escaleras
ESCALERAS_EST Texto Estado escaleras
ESCALERAS_ACT Texto Actuaciones escaleras
CUBIERTA_MAT Texto Materiales cubiertas
CUBIERTA_EST Texto Estado carpinterías
CUBIERTA_ACT Texto Actuaciones carpinterías
PATIO_MAT Texto Materiales patios
PATIO_EST Texto Estado patios
PATIO_ACT Texto Actuaciones patios
OTROS_MAT Texto Materiales otros elementos
OTROS_EST Texto Estado otros elementos
OTROS_ACT Texto Actuaciones otros elementos
ADMINISTRACIÓN
Situación administrativa
Campo Tipo Etiqueta español
DECLARACION_BIC Sí/No Declaración B.I.C.
FECHA_INCOACION Fecha/Hora Fecha incoación
FECHA_PUBLICACION Fecha/Hora Fecha publicación
FECHA_CATALOGACION Fecha/Hora Fecha de catalogación
REDACTOR_CATALOGO Texto Redactor del catálogo
OBS_REDACTOR Memo Observaciones redactor
GRADO_PROTECCION Texto Grado de protección
TIPO_INTERVENCION Texto Tipo de intervención
CRITERIO_CATALOGACION Texto Criterios de catalogación
CONSERVACIÓN
Intervenciones
Campo Tipo Etiqueta español
AUTOR Texto Autor
ANO Texto Año
FECHA_INICIO Fecha/Hora Fecha inicio
FECHA_FINALIZACION Fecha/Hora Fecha finalización
ESTADO Texto Estado
INTERVENCIONES Memo Intervenciones
Estado conservación general
Campo Tipo Etiqueta español
ESTADO_GENERAL Memo Estado general
Otras características conservación
Campo Tipo Etiqueta español
POT_ARQUEOLOGICA Sí/No Potencialidad arqueológica del subsuelo
BIENES_MUEBLES Sí/No Bienes inmuebles vinculados
DOCUMENTACIÓN
Campo Tipo Etiqueta español
DESCRIPCION Memo Datos arquitectónicos (descripción)
HISTORIA Memo Datos históricos
FUENTE_ORAL Sí/No Fuente oral
FUENTE_BIBLIOGRAFICA Sí/No Fuente bibliográfica
FUENTE_DOCUMENTAL Sí/No Fuente documental
FUENTES Memo Fuentes
OTRAS Memo Otros datos
II.ANEXO. Documento de especificaciones de la aplicación

II.1.Conceptos
Las entidades que aparecen en el contexto de nuestro problema son:
• Inventario insular de inmuebles etnográficos.
• Inventario insular de yacimientos arqueológicos.
• Inventario insular de inmuebles arquitectónicos.
• Usuarios.

II.2.Tipos de usuario (grupos o roles)

Los tipos de usuarios definidos por el sistema son:
• PC_CONSULTOR_MINIMO: Consultor anónimo que solo puede leer un
subconjunto de los datos de los inventarios.
• PC_CONSULTOR: Consultor registrado en el sistema que puede leer todo el
contenido de los inventarios pero no puede hacer modificaciones.
• PC_EDITOR: Técnico encargado del mantenimiento de los datos de un inventario.
• PC_SUPERVISOR: Técnico encargado de la supervisión de los datos introducidos
por los editores.
• PC_ADMINISTRADOR: Administrador de las bases de datos. Puede crear nuevas
bases de datos, dar de alta a nuevos usuarios y roles, etc.

II.3.Tipos de privilegios
Son los tipos de acciones que se pueden desempeñar sobre objetos de las bases de datos por
parte de los usuarios.
• Alterar: Permiso para modificar la definición de una tabla (añadir campos, renombrar,
borrar, cambiar el tipo, etc.).
• Borrar: Permiso para borrar un registro de una tabla.
• Insertar: Permiso para añadir nuevos registros a una tabla.
• Consultar: Permiso para leer los datos de una tabla.
• Actualizar: Permiso para modificar el contenido de un registro de la tabla.

II.4.Actividades
Están ordenadas según el usuario que las desempeña.
 II.4.1.PC_CONSULTOR_MINIMO

• Consultar subconjunto de campos del inventario insular de inmuebles etnográficos.

• Consultar subconjunto de campos del inventario insular de yacimientos arqueológicos.
• Consultar subconjunto de campos del inventario insular de inmuebles arquitectónicos.
• Seleccionar una zona geográfica (isla).
• Seleccionar un tipo de bien.

II.4.2.PC_CONSULTOR

• Consultar inventario insular de inmuebles etnográficos.

• Consultar inventario insular de yacimientos arqueológicos.
• Consultar inventario insular de inmuebles arquitectónicos.
• Seleccionar una zona geográfica (isla).
• Seleccionar un tipo de bien.

II.4.3.PC_EDITOR

• Incluye las acciones de PC_CONSULTOR.

• Insertar, borrar y actualizar registros del inventario insular de inmuebles etnográficos.
• Insertar, borrar y actualizar registros del inventario insular yacimientos arqueológicos.
• Insertar, borrar y actualizar registros del inventario insular de inmuebles
arquitectónicos.

II.4.4.PC_SUPERVISOR

• Incluye las acciones de PC_EDITOR.

II.4.5.PC_ADMINISTRADOR

• Incluye las acciones de PC_SUPERVISOR.

• Crear, borrar y modificar bases de datos.
• Crear, borrar y modificar roles.
• Crear, borrar y modificar usuarios.
III.ANEXO. Modelo del software

III.1.Diagramas de paquetes

sQeletor PerenQen

PC

phpMVC

Ext_Libs IQ_Libs
III.2.Diagramas de clases del software

III.2.1.PC
III.2.2.PerenQen
III.3.Diagramas se secuencia

III.3.1.PC
III.3.2.phpMVC
III.3.3.PerenQen
IV.ANEXO. Frameworks para aplicaciones web
Este apéndice contiene una lista de los frameworks más importantes que podemos encontrar
actualmente en el mercado con sus principales características. Se puede obtener una lista más
completa y actualizada en la dirección http://www.phpwact.org/php/mvc_frameworks

IV.1.phpMVC
• Web: http://www.phpmvc.net/
• Autor/Equipo: John Wildenauer.
• Estado: Versión 0.3 beta, con amplia documentación y en desarrollo la versión para
PHP5. Parece bastante activo.
• Licencia: LGPL.
• Ventajas: Se trata de un port de STRUTS de Java que es uno de los más usados para
esa plataforma.
• Desventajas: Parece que solo hay un desarrollador y es a nivel personal.

IV.2.Phrame
• Web: https://www.phrame.org/
• Autor/Equipo: Inicialmente apoyado por Software Development Department of
Texas Tech University.
• Estado: Versión 3.0.3. Con documentación un poco pobre. Parece bastante activo.
• Licencia: LGPL.
• Ventajas: Es un port de STRUTS.
• Desventajas: Parece en estado menos avanzado que phpMVC.

IV.3.WACT
• Web: http://www.phpwact.org/
• Autor/Equipo: Empresa Procata Inc.
• Estado: Versión 0.2 Alfa. Bastante documentación y ejemplos.
• Licencia: CC (Creative Commons).
• Ventajas: Parece bastante avanzado.
• Desventajas:
IV.4.eocene
• Web: http://www.eocene.net
• Autor/Equipo:
• Estado: Desaparecido.
• Licencia:
• Ventajas:
• Desventajas:

IV.5.Ambibalence
• Web: http://amb.sourceforge.net/
• Autor/Equipo: Loren Siebert.
• Estado: Versión 0.3. No parece muy activo.
• Licencia: Estilo Apache.
• Ventajas: Documentación pobre. No hay ejemplos.
• Desventajas: Parece una versión demasiado inicial.

IV.6.Krysalis
• Web: http://www.kompletecms.com/products/Krysalis/
• Autor/Equipo: Empresa InterAkt. Fundada en 2001 y con 30 empleados.
• Estado: Versión 2.4.1.
• Licencia: LGPL para los productos gratis.
• Ventajas: Desarrollado por una empresa. Soporte para varios sistemas de bases de
datos. Amplia documentación. Incluye un entorno de desarrollo.
• Desventajas: Hay tres versiones y las profesionales son de pago. No es un port de
algún estándar libre. Pertenece a una empresa privada que puede dejar de dar soporte
en cualquier momento.

IV.7.Ismo
• Web: http://sourceforge.net/projects/ismo/
• Autor/Equipo: 4 desarrolladores.
• Estado: Versión pre alfa 0.1.4. Parece inactivo, la última versión es de junio del 2004.
• Licencia: PHP.
• Ventajas:
• Desventajas:
IV.8.BinaryCloud
• Web: http://www.binarycloud.com/
• Autor/Equipo: No aparece en la web.
• Estado: Versión 3.0.0.
• Licencia: GNU FDL.
• Ventajas: Amplia documentación.
• Desventajas: No es un estándar, el diseño del software es propio.

IV.9.Mojavi
• Web: http://www.mojavi.org/
• Autor/Equipo: Sean Kerr.
• Estado: Versión 3.0. Última versión estable la 2.0.0. Parece activo.
• Licencia: LGPL.
• Ventajas:
• Desventajas: No parece respaldado por una empresa o conjunto de desarrolladores
grande.

IV.10.Horde
• Web: http://www.horde.org/horde/
• Autor/Equipo: 9 desarrolladores.
• Estado: Versión 3.0.6.
• Licencia: LGPL.
• Ventajas: Está muy desarrollado y hay una gran número de aplicaciones que lo
utilizan.
• Desventajas: No existe documentación de cómo usarlo solo directamente la API.

IV.11.PHITE
• Web: http://www.dreammask.com/PHITE.php?sitesig=PT
• Autor/Equipo: Cris Robson.
• Estado: Versión 0.92.
• Licencia: GPL.
• Ventajas: Está inspirado en ZOPE.
• Desventajas: Es un sencillo script para la creación rápida de webs que no sirve para
aplicaciones muy complejas.

IV.12.Blueshoes
• Web: http://www.blueshoes.org/
• Autor/Equipo:
• Estado: Versión 4.5.
• Licencia: Versión comercial y open source.
• Ventajas:
• Desventajas: Para propósitos comerciales es de pago.

IV.13.Cake PHP
• Web: http://cakephp.org/
• Autor/Equipo: 9 desarrolladores.
• Estado: Versión 0.10.0.
• Licencia:
• Ventajas: Compatible con PHP 4 y PHP 5. Amplia documentación. Está inspirado en
Ruby on Rails, que está actualmente en alza.
• Desventajas:

IV.14.phpwebtk
• Web: http://phpwebtk.sourceforge.net/
• Autor/Equipo: Brian Bisaillon y otro desarrollador.
• Estado: Versión 1.0.3 Alfa.
• Licencia: LGPL.
• Ventajas:
• Desventajas: No es un port de algún otro estándar reconocido.

IV.15.studs
• Web: http://mojavelinux.com/projects/studs/
• Autor/Equipo: Dan Allen.
• Estado: Vesrión 0.9.7.
• Licencia: Apache 2.0.
 • Ventajas: PHP4 y PHP 5. Se trata de un port de STRUTS de Java. Amplia
documentación.
• Desventajas:

V. ANEXO. Motores de persistencia para PHP

La lista de motores de persistencia disponibles para PHP está obtenida de la web de Wikipedia
(http://en.wikipedia.org/wiki/Object-relational_mapping#PHP) en el artículo titulado Object-
SQL mapping, que se refiere a la técnica usada en programación para enlazar programas
orientados a objetos con bases de datos relacionales.

También se puede obtener una comparativa de los motores que existen actualmente en una de
las páginas de un tutorial de uno de ellos (Propel): http://propel.phpdb.org/docs/user_guide/.

V.1.Metastorage
Web: http://www.meta-language.net/metastorage.html

Metastorage es una aplicación que genera código automáticamente para una API orientada
a objetos, y tiene como finalidad la gestión del almacenamiento, recuperación y
manipulación de objetos persistentes.

Se trata de una librería que, a partir de la información de los objetos que queremos hacer
persistentes, nos compila una serie de clases para su manipulación, y nos crea los
esquemas para las bases de datos. Algunas de sus capacidades son:

• Formato de definición XML: fichero de configuración XML donde se especifican

los objetos persistentes con sus atributos.
• Generación de los esquemas para las bases de datos.
• Generación automática de todo el código.
• Código independiente de otros paquetes.
• Soporta Object Query Language (OQL), que es la versión de SQL orientada a
objetos.
• No es necesario para el desarrollador usar SQL.
 • Genera los formularios para manejar los objetos de las clases de objetos
persistentes.
• Generación automática de diagramas en UML con las relaciones entre clases.

Ventajas:

• Open source.

Desventajas:

• Procesos de generación y compilación.

• Las clases quedan ligadas a la persistencia, es decir, las clases que son persistentes
son generadas por Metastorage con métodos para crearlas, almacenarlas, etc.
• No independencia del dominio con respecto al motor de persistencia. Es costoso
cambiar de motor de persistencia.

V.2.Propel
Web: http://propel.phpdb.org/trac/

Se trata, según la web, de "un kit de herramientas completo para la consulta y

almacenado de objetos". Esencialmente se trata de una librería que independiza a la
aplicación de la gestión de las bases de datos para el almacenaje de los objetos
persistentes. El funcionamiento es similar a Metastorage, utiliza un fichero de
configuración en XML donde el programador define los objetos con sus atributos y
relaciones. En el ejemplo del tutorial podemos ver como funciona:
1. Primero creamos el fichero con las definiciones de los tipos de objetos.

<?xml version="1.0" encoding="ISO-8859-1"?>

<database name="bookstore">
<table name="book">
<column name="book_id" type="INTEGER" required="true"
primaryKey="true"/>
<column name="title" type="VARCHAR" size="50"
required="true" />
</table>
</database>

2. Al construir este modelo se crearán varias clases que se usarán para añadir,
actualizar, borrar y buscar datos en la tabla de libros (book). Propel generará
 también un conjunto de subclases para personalizar su comportamiento sin
necesidad de hacer cambios a las clases creadas, las cuales serán regeneradas más
tarde cuando se cambie el modelo de objetos. Las clases generadas para el modelo
del ejemplo son:

BaseBook representa la clase base para un registro de la tabla "book".

Book es la clase vacía donde se pueden añadir las personalizaciones. Las consultas
devolverán vectores de objetos Book.

BaseBookPeer es una clase con solo métodos estáticos (no es necesario crear
instancias) que se encarga de la manipulación de los datos en la tabla.

BookPeer es una subclase vacía de BaseBookPeer que es la que debe usarse en el

código. Sirve para personalizaciones.

BookMap contiene el mapeo con la base de datos. En vez de tener que ejecutar lentas
consultas a la base de datos acerca de metadatos (por ejemplo saber que columnas son
clave primaria, claves externas, etc.), Propel compila una clase de mapeo que puede
devolver rápidamente información relevante acerca de la estructura de la tabla.

3. En el código podemos utilizar la clase Book como cualquier otra clase de PHP.
Propel será el encargado de gestionar el SQL y las llamadas a la base de datos. Un
ejemplo de uso que encontramos en el tutorial es el siguiente:

// example using business objects

$b = new Book();
$b->setTitle("War & Peace");
$b->save();

// "peer" class is static class that handles things like queries

$c = new Criteria();
$c->add(BookPeer::TITLE, "War%", Criteria::LIKE);
$c->setLimit(10);

$books = BookPeer::doSelect($c);

foreach($books as $book) {
print "<br/>" . $book->getTitle();
}

Ventajas:
 • Es un port de otro sistema utilizado de Java: Apache Torque.
• Parece el más avanzado y robusto de los proyectos, incluye una amplia
documentación.
• Implementa las relaciones entre las tablas con las claves externas.
• Genera clases para la personalización, no se usan sus clases directamente.
• Es mejor usar un software de desarrollo externo a desarrollar un software propio.
De esta manera se disponen de actualizaciones, nuevas capacidades, corrección de
bug, etcétera, a un coste cero. Si se usa un software propio es necesario
implementar cualquier nueva capacidad o necesidad.

Desventajas:

• Está hecho para PHP 5, el cual es muy reciente y no todos los servidores lo
soportan.
• Es necesario generar las clases, lo cual implica que ante cualquier cambio en una
clase tenemos que regenerar el código.
• Genera para cada tipo de objeto persistente cinco clases diferentes, lo cual redunda
en una gran cantidad de clases.
• Las clases del dominio heredan de las de persistencia.
• Hay un intermediario de persistencia para cada clase. En PerenQen, por el
contrario, solo hay una clase intermediario que gestiona el almacenamiento de
todas las clases, lo cual simplifica la generación de código, disminuye el número
de fallos producidos por no emplear la clase correcta, y facilita la personalización
de los intermediarios. En el caso de Propel al añadir un método a un intermediario
sería necesario añadirlo a todos los del resto de las clases persistentes.

En general parece una opción a tener en cuenta en desarrollos nuevos para PHP 5. Tendría
que hacerse un estudio más profundo para comprobar como afectaría su uso en el
rendimiento (si es rápido), en el desarrollo (si la generación de las clases en demasiado
engorrosa y debe hacerse a menudo), y en la flexibilidad para poder añadir nuevas
funcionalidades al motor como nuevos métodos a los intermediarios, nuevos drivers, etc.

V.3.DA_Data_object
Web: http://pear.php.net/manual/en/package.database.db-dataobject.php
 Es una clase de PEAR cuyo propósito es:

• Construir y ejecutar SQL basado en objetos.

• Agrupar el código relativo a la gestión de los datos.
• Proveer de una interfaz sencilla para la manipulación de los datos.
Se trata de una clase que incorpora métodos para el acceso a los datos de una base de
datos. Para usarla es necesario que los objetos que sean persistentes hereden de esta clase.
De esta manera podemos incluir a cualquier objeto los métodos relativos a la persistencia,
que serán aquellos que nos permitan recuperar objetos, almacenarlos, etc.

Ventajas:

• Es de PEAR, una librería con amplia documentación y tradición.

• Es fácil de usar.

Desventajas:

• Acopla el dominio al motor de persistencia al hacer que las clases del dominio
hereden de las del motor de persistencia. Esto hace difícil cambiar a otro tipo de
motor de persistencia que no cumpla con una misma interfaz.

V.4.POG
Web: http://www.phpobjectgenerator.com/

POG (PHP Object Generator) es una página web que a partir de la especificación del
nombre, y de los atributos de una clase, genera el código necesario para gestionar el acceso a
la base de datos de esa clase.

Desventajas:

• Es realmente sencillo y trivial.

• Se repite código en todas las clases.
• Las clases están fuertemente acopladas al acceso a la base de datos.
 V.5.Cake PHP
Web: http://cakephp.org/

Es un framework para PHP que incluye facilidades para la gestión de las bases de datos.

Desventajas:

• Es demasiado reciente.
• No está documentado aún.