share-COIICV Temario 2

TEMARIO PARA OPOSICIONES VOL. 2 (T.
21 a 40)
CUERPO SUPERIOR TÉCNICO

DE TECNOLOGÍAS DE LA INFORMACIÓN
DE LA ADMINISTRACIÓN DE LA GENERALITAT VALENCIANA
Se autoriza el uso exclusivo de este documento a Laura Andrés Sauco, DNI 21009879T, a 8 de enero de 2021
Temario de oposiciones al Cuerpo Superior Técnico de tecnologías de la
información de la administración de la Generalitat Valenciana
Varios autores
Editado por el Colegio Oficial de Ingeniería Informática de la Comunitat
Valenciana (COIICV)
CIF: V-97046189
Av. del Oeste 48, 3º O. 46001 Valencia
963622994 – secretaria@coiicv.org
www.coiicv.org
Primera edición: junio de 2019

Segunda edición: diciembre de 2019
ISBN de la obra: 978-84-09-12590-6
ISBN del volúmen: 978-84-09-12911-9
© Colegio Oficial de Ingeniería Informática de la Comunidad Valenciana

(COIICV) 2019.
Todos los derechos reservados. Se autoriza el uso y consulta de esta obra

exclusivamente al adquirente del presente ejemplar de la misma, quedando
expresamente prohibido su uso por cualquier tercero no autorizado por COIICV
así como cualquier utilización con fines comerciales de su contenido sin la
expresa autorización del COIICV, lo cual incluye especialmente cualquier
reproducción, modificación, registro, copia, explotación, distribución,
comunicación, transmisión, envío, reutilización, publicación, tratamiento o
cualquier otra utilización total o parcial, en cualquier modo, medio o formato de
esta publicación.
Contenido Volumen 2
Tema 21. Computación móvil. Cloud computing. Almacenamiento en la nube. Procesamiento en la
nube. Nubes privadas, públicas e híbridas. Seguimiento y control de calidad de productos y
servicios de computación móvil. IaaS, PaaS, SaaS.
Tema 22. Virtualización de sistemas. Servidores de datos y de aplicaciones. Sistemas de

almacenamiento.
Tema 23. Tratamiento de información multimedia.
Tema 24. Arquitecturas de sistemas de información. El procesamiento cooperativo y la arquitectura

cliente-servidor.
Tema 25. Arquitectura SOA.
Tema 26. Concepto, evolución y tendencias de los sistemas operativos. Los sistemas UNIX y
LINUX. Los sistemas Microsoft Windows. Los sistemas Android.
Tema 27. Gestión de entornos basados en servidores con sistema Microsoft. Gestión dominios.
Active directory. Protocolos.
Tema 28. Los sistemas de gestión de bases de datos SGBD. El modelo de referencia de ANSI. El
modelo relacional. El lenguaje SQL. Bases de datos no relacionales. Bases de datos no
estructuradas. NoSQL.
Tema 29. Tecnologías para el desarrollo de aplicaciones: Microsoft.NET, JAVA, PHP. Frameworks
de desarrollo.
Tema 30. Herramientas de generación de código gvNIX y gvHIDRA.
Tema 31. Software de código abierto. Software libre. Conceptos base. Aplicaciones y usos.
Normativa sobre propiedad intelectual. Tipos de licenciamiento de aplicaciones informáticas.
Tema 32. Sistemas CRM (Customer Relationship Management) y ERP (Enterprise Resource
Planning). Beneficios y usos.
Tema 33. E-learning: Conceptos, herramientas, implantación y normalización.
TEMARIO OPOSICIONES COIICV I
Contenido Volumen 2
Tema 34. Los sistemas de información geográfica. Conceptos y funcionalidad básicos. El proyecto
gvSIG. Incorporación de la componente geográfica en los sistemas de información.
Tema 35. Infraestructuras de datos espaciales. Definición y componentes. Legislaciones vigentes

(INSPIRE y LISIGE). Arquitectura de una IDE. Servicios web de una IDE: mapas, catálogo, objetos
geográficos, geoprocesamiento y observación de sensores. Aplicaciones geoespaciales.
Tema 36. Gestión de los datos corporativos. Almacén de datos (data-warehouse). Arquitectura
OLAP. Minería de datos. Arquitecturas y técnicas de procesamiento masivo de datos (big data).
Tema 37. Diseño y desarrollo de portales web. Lenguajes y herramientas para la utilización de
redes globales. HTML y XML.
Tema 38. Comercio electrónico. Pasarelas de pago. Factura electrónica. Servicios ge-Factura y
FACE.
Tema 39. Servicios de autenticación. Certificados digitales. Localización de claves públicas.

Servicios de directorio. Marcos de autenticación. Otras técnicas de autenticación.
Tema 40. Infraestructura de clave pública (PKI): definición y elementos de una PKI. Prestación de
servicios de certificación públicos y privados. Autoridades de certificación. El DNI electrónico.
II TEMARIO OPOSICIONES COIICV
Tema 21. Computación móvil. Cloud computing.
Almacenamiento en la nube. Procesamiento en la
nube. Nubes privadas, públicas e híbridas.
Seguimiento y control de calidad de productos y
servicios de computación móvil. IaaS, PaaS, SaaS
José Miguel Sánchez Vallés

Colegiado 0315
El aumento de la cantidad de información que producen los sistemas de información,

el aumento de cantidad de cómputo así como la mayor madurez en el uso de internet
junto con la mejora de los sistemas de comunicación ha provocado la aparición de
nuevos paradigmas.
Cloud Computing es un nuevo paradigma que incluye una nueva concepción

tecnológica además de un nuevo modelo de negocio. Dicho paradigma está basado en
la exposición, gestión, uso de recursos, servicios e infraestructuras a través de
internet.
El Cloud computing está basado en la virtualización de recursos en internet. Algunas

de sus características son, Pago por el uso que hagas de los recursos, abstracción de
la implementación física de los recursos, facilidad de escalabilidad, adaptación
Elástica a la demanda de peticiones de servicio y agrupación de los recursos por tipo.
El Cloud computing proporciona tanto beneficios económicos, como Tecnológicos así

como organizativos tanto para las organizaciones como para los particulares.
Sin embargo no son todo ventajas también presenta inconvenientes como la falta de
privacidad y riesgo de vulnerabilidad de la información.
Se disponen cuatro modelos de desarrollo del Cloud computing en base a los distintos
tipos de nube en función de su privacidad: Las nubes públicas, privadas, Híbridas y de
comunidad. Cada una presenta sus ventajas e inconvenientes en función del cliente
de la nube y los servicios proporcionados.
Existen tres tipos principales de tipos de servicios proporcionados por el Cloud

Computing, Software as Service (Saas) Aquellos servicios que son accedidos a través
de un thin Client, Platform as a Service (Pass) en el que el modelo de servicio está
basado en el despliegue de aplicaciones y recursos de infraestructura e Infraestructura
as a Service (Iaas) se proporcionan proporciona posibilidades a las organizaciones
TEMARIO OPOSICIONES COIICV | TEMA 21 1
que necesiten adaptar sus recursos de procesamiento y almacenamiento de una

manera elástica, eficiente y que aumenta o disminuye bajo demanda.
En la actualidad las posibilidades que presenta Cloud computing están siendo

explotadas por muchas organizaciones bien como parte de la optimización de los
costes de gestión o bien como parte de su modelo de negocio. La democratización de
internet y la madurez de los modelos de virtualización hacen de esta tecnología una de
las más atractivas y con mayor posibilidad de crecimiento. No obstante la dependencia
de las comunicaciones se presenta un importante obstáculo a la hora de su
implantación.
1. Computación Móvil
La globalización y las deslocalización de las grandes empresas, así como el aumento de la

cantidad de información que producen y que reutilizan está creando que el aumento de la
necesidad de cómputo y procesamiento de datos esté aumentado más rápido que la capacidad de
la que disponen los ordenadores personales. Esto ha hecho que las arquitecturas de
proceso/almacenamiento hayan tenido que evolucionar hacia métodos de ejecución simultánea y
colaborativa entre varios equipos informáticos.
Con la democratización de Internet, ha sido posible la aparición de muchos paradigmas cuya

finalidad es ofrecer soluciones tecnológicas como un servicio. Internet permite la descentralización,
que equipos individuales puedan conectarse con otros que se encuentran en un lugar del mundo
diferente. Esta forma de interconexión hace que podamos obtener una mayor cantidad de recursos
de cómputo y de almacenamiento de forma distribuida. Los nuevos paradigmas, tales como la Web
2.0, computación P2P, data centers, clúster, grid, computación ubicua, etc., pretenden explotar
todo este potencial.
Sin embargo y para centrarnos más en el origen de lo que hoy conocemos como cloud computing,
vamos a detenernos sólo en las definiciones de dos paradigmas de computación bastante usados
o estudiados, como son la computación en clúster y en grid.
Greg Pfister (gurú en clusters) define un clúster como un tipo de sistema paralelo que consiste en
la interconexión de equipos individuales para actuar como uno solo. Considera que un equipo
individual es aquel que es independiente y puede funcionar por sí mismo, es lo que se conoce
como un nodo. Por lo tanto, un clúster es una configuración de un grupo de nodos, que aparecen
en la red como una sola máquina y actúan como tal. Puede ser administrado como un solo sistema
y además está diseñado para tolerar fallos en los componentes, de manera que si uno falla, el
usuario no se percate de ello. Además, existen varios tipos de clúster; puede ser que todos los
equipos sean similares en cuanto a hardware y software, por lo que estaremos hablando de clúster
homogéneo; si difieren en rendimiento pero tienen similitudes, se trata de un clúster semi-
homogéneo y en cambio, si tanto el hardware como el software son diferentes, se conoce como
clúster heterogéneo. Este último tipo es el más sencillo y económico.
2 TEMARIO OPOSICIONES COIICV | TEMA 21
Computación móvil. Cloud computing
Podemos considerar un grid como una especialización de un clúster, los centros de investigación y
las universidades que disponían de estos sistemas clúster, comenzaron a ofrecer los servicios de
cálculo y almacenamiento a terceros, a través de protocolos estándar, dando lugar a la que hoy en
día se denomina computación grid. Por lo tanto, la computación grid, o también conocida como
computación distribuida, consiste en un gran número de equipos organizados en clústeres y
conectados mediante una red de comunicaciones. Está orientada al procesamiento en paralelo y al
almacenamiento de grandes cantidades de información. Permite compartir una amplia variedad de
recursos que están distribuidos geográficamente.
Entre estos recursos se pueden encontrar grandes computadoras, sistemas de almacenamiento,

etc…
A pesar de que este tipo de computación ofrece muchas ventajas, tales como la potencia,
escalabilidad, integración de sistemas heterogéneos, etc…, solo tuvieron éxito dentro del ámbito
académico y de investigación. Esto fue debido a la complejidad para utilizar la infraestructura y los
problemas de portabilidad entre grids.
El siguiente paso tras los clústeres y la computación en grid, fue la virtualización. Esta nueva
tecnología consiste en la creación virtual de algún recurso, que puede ser un sistema operativo, un
servidor, un dispositivo de almacenamiento, recursos de red, etc. Esto tiene muchas ventajas,
debido a que es posible replicar un entorno sin necesidad de instalar y configurar todo el software
que requieren las aplicaciones. La virtualización simula una plataforma de hardware autónoma y
ejecuta el software como si este estuviera instalado.
Esta nueva tecnología permite distribuir la carga de trabajo de una manera mucho más sencilla que
en la computación grid. Y también permite, como la anterior, la integración de entornos
heterogéneos. Así es como surge el nuevo paradigma de computación, el cloud computing. Las
plataformas de cloud computing tienen características de ambas tecnologías, los clústeres y los
grids, pero añade sus propias ventajas.
2. Cloud Computing
El término cloud computing hace referencia a un nuevo paradigma, a una concepción tecnológica y
a un modelo de negocio que reúne entre otras ideas tan diversas como el almacenamiento de
información, las comunicaciones entre ordenadores, la provisión de servicios o las metodologías de
desarrollo de aplicaciones, todo ello bajo el mismo concepto: todo ocurre en la nube. La nube es el
conjunto de servicios e infraestructuras accesibles por internet.
La computación en la nube es una tecnología nueva que busca tener todos nuestros archivos e
información, computadoras con capacidad de proceso, sistemas de comunicaciones así como la
mayoría de nuestros recursos hardware en Data Centers accesibles a través de Internet, sin
preocuparse por poseer la capacidad suficiente para almacenar información o de computación en

nuestro sistemas físicos.
El cloud computing explica las nuevas posibilidades de forma de negocio, ofreciendo servicios a
través de Internet, conocidos como e-business (negocios por Internet).
2.1. Características del Cloud Computing
Una de las principales características del Cloud Computing es que no hay necesidad de conocer la
infraestructura detrás de esta, pasa a ser "una nube" donde las aplicaciones y servicios pueden
fácilmente crecer (escalar), funcionar rápido y casi nunca fallan, sin conocer los detalles del
funcionamiento de esta "nube".
Este tipo de servicio se paga según alguna métrica de consumo, no por el equipo usado en sí, sino
por ejemplo en el consumo de electricidad o por uso de CPU/hora como en el caso de Amazon
EC2.
Se definen algunas de sus características más importantes:
• Pago por uso: una de las características principales de las soluciones cloud es el modelo
de facturación basado en el consumo. El cliente paga por los servicios
contratados/Consumidos.
• Abstracción: La abstracción corresponde a olvidar los detalles de la implementación por

parte de los usuarios y los desarrolladores, tomando este concepto desde un enfoque en
donde las aplicaciones se ejecutan sobre una maquina física que no está especificada, los
datos son almacenados en ubicaciones desconocidas, la administración de los sistemas
está bajo responsabilidad de un tercero y finalmente los usuarios tienen acceso a esta
infraestructura desde cualquier lugar con acceso la red. En cuanto a la virtualización se
refiere a la habilidad del sistema para crear sistemas que parezcan independientes ante los
usuarios a través de mecanismos de compartir y asignar periodos de uso a los recursos
que cada unidad necesita. Cloud Computing.
• Agilidad en la escalabilidad: Característica o capacidad consistente en aumentar o

disminuir las funcionalidades ofrecidas al cliente, en función de sus necesidades puntuales
sin necesidad de nuevos contratos ni penalizaciones. De la misma manera, el coste del
servicio asociado se modifica también en función de las necesidades puntuales de uso de
la solución. Esta característica, relacionada con el pago por uso, evita los riesgos
inherentes de un posible mal dimensionamiento inicial en el consumo o en la necesidad de
recursos.
• Multiusuario: Capacidad que otorga el cloud que permite a varios usuarios compartir los
medios y recursos informáticos, permitiendo la optimización de su uso.
• Autoservicio bajo demanda: permite al usuario acceder de manera flexible a las

capacidades de computación en la nube de forma automática a medida que las vaya
requiriendo, sin necesidad de una interacción humana con su proveedor o proveedores de
servicios cloud.
• Acceso sin restricciones: Característica consistente en la posibilidad ofrecida a los

usuarios de acceder a los servicios contratados de cloud computing en cualquier lugar, en
cualquier momento y con cualquier dispositivo que disponga de conexión a redes de
servicio IP. El acceso a los servicios de cloud computing se realiza a través de la red, lo
que facilita que distintos dispositivos, tales como teléfonos móviles, tablets, ordenadores
portátiles, puedan acceder a un mismo servicio ofrecido en la red mediante mecanismos de
acceso comunes.
• Acceso a redes de banda ancha de acuerdo con el NIST (National Institute of Standard
and Technology) , debe ser posible acceder a la red en la nube desde cualquier lugar y por
medio de cualquier dispositivo (por ejemplo, teléfono inteligente, laptop, dispositivos
móviles, Tablets).
• Agrupación de recursos: los recursos informáticos del proveedor se agrupan para prestar
servicios a diversos clientes utilizando un modelo de múltiples usuarios, con diferentes
recursos físicos y virtuales asignados y reasignados de manera dinámica según la
demanda. Existe un sentido de independencia geográfica. Generalmente, el cliente no
tiene control o conocimiento de la ubicación exacta de los recursos proporcionados. Sin
embargo, puede ser capaz de especificar una ubicación en un nivel de abstracción mayor
(por ejemplo, país, región o centro de datos). Los ejemplos de recursos incluyen
almacenamiento, procesamiento, memoria, ancho de banda de la red y máquinas virtuales.
• Rápida elasticidad: las capacidades se pueden suministrar de manera rápida y elástica,

en muchos casos automáticamente, para una rápida expansión y liberar rápidamente para
una rápida contracción. Para el cliente, las capacidades disponibles para suministro,
parecen ser ilimitadas, además, se puede adquirir cualquier cantidad de capacidades en
cualquier momento Servicio con capacidad de medida: Los sistemas en la nube
controlan y optimizan el uso de recursos de manera automática utilizando una capacidad
de medición (por ejemplo, almacenamiento, procesamiento, ancho de banda y cuentas de
usuario activas). El uso de los recursos se puede monitorear, controlar y notificar, lo que
proporciona transparencia tanto para el proveedor como para el cliente que utiliza el
servicio.
2.2. Ventajas del Cloud Computing
Las ventajas o beneficios del Cloud Computing se clasifican según el marco en económicos,
tecnológicos u organizativos.
2.2.1. Beneficios económicos
Reducción de costes de mantenimiento: El Cloud Computing permite reducir los costes de

mantenimiento, soporte y ahorro de energía de los sistemas de información existentes, además
proporciona un ahorro en el despliegue de nuevas infraestructuras. No es necesario el pago de
licencias o las actualizaciones de versiones, suelen ir incluidas en el coste del servicio.
Flexibilidad: Reacción más rápida ante los cambios en las condiciones del mercado, incorporando
servicios adicionales cuando sea necesario por parte del proveedor de Cloud.
Los beneficios económicos son especialmente importantes para las empresas que no disponen de
suficientes recursos facilitándoles ser competitivas al proporcionarles la oportunidad de adoptar
nuevos desarrollos de Tecnologías de la Información (TIC) con costes razonables al adoptar el
modelo de pago por consumo y disminuir los costes de mantenimiento.
2.2.2. Beneficios Tecnológicos
Facilita el despliegue en la implantación, no es necesario infraestructura (hardware, software y

comunicaciones) aunque también depende de la especificidad y complejidad de los servicios
solicitados. Asimismo se simplifican las tareas de actualizaciones, mantenimiento y soporte.
Los aspectos de seguridad de la información se ven facilitados al realizar una gestión

centralizada que permite que el proveedor de servicios TI proporcione accesos seguros que
garanticen la privacidad y confidencialidad de la información (encriptación de datos, https,
Kerberos, etc.) y una completa protección antivirus. Además debe garantizarse el funcionamiento y
la estabilidad del sistema en un marco 24/7 por medio de la utilización de infraestructuras a prueba
de fallos y líneas replicadas y disponiendo de alternativas para proporcionar el servicio por otros
medios y en otras ubicaciones en el menor tiempo posible. Se proporciona de esta forma una
mejora en la capacidad de adaptación y de recuperación de desastres así como una reducción de
los tiempos de inactividad.
Proporciona Elasticidad que permite hacer frente a aumentos y disminuciones de las cargas de
los sistemas de información provocados por variaciones en la actividad de áreas funcionales y
procesos de negocio, con el menor coste posible.
La responsabilidad en el desarrollo y operación de los sistemas de información puede transferirse

parcialmente a la empresa suministradora de Cloud. Se suprime también la complejidad en los
procesos de actualización en las versiones.
Mayor respeto por el medio ambiente, dado que al centralizar los servicios se produce un menor
consumo de energía (partida importante de los costes de la infraestructura de TI) y una reducción
en el impacto medioambiental.
2.2.3. Beneficios Organizativos
Disminuye la dimensión y la orientación del departamento de TI así como la necesidad de

disponer de personal formado. Se aumentan también las posibilidades de comunicación,
colaboración y registro de la información dado que se puede acceder a toda la información desde
cualquier lugar, momento o dispositivo. En la actualidad, en modalidad Cloud Computing se
pueden aprovechar una nueva generación de aplicaciones sociales que fomentan la colaboración
dentro de la organización pero también con proveedores o clientes, que sería complicado
desplegar con los recursos propios de la organización.
El Cloud Computing ofrece también una oportunidad de cambio: plantearse hacer las cosas de
forma distinta, identificando costes ocultos e inercias organizativas y provocado por el creciente
número de aplicaciones web disponibles que son un acicate para el planteamiento de nuevos
procesos o el rediseño de los ya existentes.
Debido a la estandarización y factores relacionados con la difusión de la tecnología y el empleo

de interfaces amigables las aplicaciones y servicios web disponibles son fáciles de utilizar,
disminuyendo, de esta forma, la curva de aprendizaje: el usuario no tiene que estar familiarizado
con los aspectos tecnológicos que hay detrás, accediendo de forma directa a través de la red sin la
interacción de un tercero. Además, la disminución en el uso fraudulento del software y la piratería
tienen un impacto beneficioso tanto en la cultura organizativa de la empresa como en el riesgo de
sufrir sanciones.
2.3. Desventajas del Cloud Computing
La adopción del Cloud Computing se enfrenta a una serie de obstáculos y resistencias que las
empresas, de una forma más o menos objetiva, tienen. Existe una preocupación sobre el cómo
adoptar este modelo, puede afectar a la disponibilidad de los servicios TI y también a su impacto
sobre la seguridad de la información. De forma similar al planteamiento seguido para los
beneficios, las desventajas pueden clasificarse en aspectos tecnológicos y aspectos organizativos.
2.3.1. Aspectos tecnológicos
La seguridad es un aspecto importante para la mayoría de las empresas. Se entiende que se va a

estar expuesto a un número mayor de riesgos y vulnerabilidades al producirse un traslado de
información de una red protegida a una red pública, pudiendo sufrir ataques o una merma de la
confidencialidad. Los temores surgen porque las empresas creen que pierden el control de la
información y que al compartir infraestructura aumentan los posibles riesgos a la seguridad debido
a accesos no autorizados. Una alternativa que mejora la seguridad es el empleo de nubes
privadas. En cualquier caso, es importante conocer con claridad las garantías con las que se
ofrece un servicio Cloud.
También se presentan temores respecto a las siguientes circunstancias:
• Falta de privacidad. Ante la ausencia de una suficiente cobertura legal (o incluso con
ella). Los datos de una organización podrían ser comercializados y adquiridos por terceros;
incluso por empresas de la competencia, logrando información ventajosa sobre productos o
cuentas de clientes. No obstante, Hay que preguntarse en qué se diferencian los datos
alojados en la nube de los que maneja una entidad financiera o la información asociada a
una operación en línea realizada mediante una tarjeta de crédito. En estos casos, los datos
“viajan” y no es objetivo pensar que están más seguros en un servidor propio que en el de
un reputado proveedor externo.
• No se tiene control ante incidentes informáticos de diversa índole sobre la Integridad de la

información. Este concepto está relacionado con la fiabilidad del servicio suministrado,
al considerar que se trata de un sistema que no está convenientemente probado.
• Situación de “cautividad” respecto de los proveedores de servicios Cloud por varias

razones: falta de estandarización, poca (o nula) interoperabilidad de los servicios
existentes, acuerdos de nivel de servicio (SLA) mal definidos y con requerimientos
insuficientes, etc.
• Se considera que la inercia al cambio puede ser también un obstáculo que impida la
adopción de la perspectiva Cloud, especialmente en empresas maduras y con sistemas de
información consolidados y que pueden estar funcionando de forma satisfactoria.
• Dependencia del estado de las comunicaciones del estado del servicio. Por falta de
calidad de las comunicaciones, interrupciones. Dado que si Internet no está disponible el
usuario no tendrá acceso al programa. Podría producirse interrupción en el servicio por
razones achacables al propio proveedor, como no disponer de una capacidad suficiente.
• Disminución de la libertad y creatividad para introducir mejoras y personalizaciones en

las distintas capas de los sistemas de información.
• No se dispone de métricas que permitan evaluar los parámetros de calidad de servicio y

que fundamenten una queja razonada ante una pérdida de calidad.
2.3.2. Aspectos organizativos
En este bloque se consideran aquellos inconvenientes en el ámbito organizativo que son

percibidos por las empresas. Entre ellos cabe citar:
La dependencia del proveedor originada por la centralización de las aplicaciones y el

almacenamiento de los datos. Esta dependencia origina una sensación de cautividad: no resultará
fácil migrar a otro servicio y tendrá asociados una serie de costes económicos y riesgos para los
procesos de negocio de la organización. Este temor aparece fortalecido si se considera la
aparición de planteamientos monopolísticos por parte de las empresas proveedoras de servicios.
Asociada al obstáculo percibido de la dependencia y la cautividad se encuentra la percepción falta
de cobertura legal o el empleo de legislación extranjera que permita definir unos acuerdos de
niveles de servicio SLA (Service Level Agreement) adecuados. Una circunstancia que debe ser
tenida en cuenta es la falta de una comprensión de las implicaciones reales de utilizar este tipo de
servicio.
En resumen, quizá las empresas estarán más dispuestas a adoptar de forma amplia el Cloud
Computing cuando pueda asegurarse el cumplimiento de normativas relativas a la seguridad
(protección de datos) a través de toda la empresa, la integración de la información crítica para el
negocio y los procesos empresariales o la gestión completa del ciclo de vida de la aplicación, con
independencia del mecanismo de descarga. A todo esto hay que unir unas garantías de calidad de
servicio, alta fiabilidad, seguridad y alta disponibilidad.
3. Nubes privadas, públicas e híbridas
Una de las clasificaciones que se puede realizar de los distintos tipos de nube se hace atendiendo
a la privacidad. De esta manera, encontramos cuatro modelos de desarrollo para el cloud
computing: nube pública, privada, híbrida y comunitaria.
3.1. Nube Pública
Una nube se dice que es una nube pública cuando los servicios ofrecidos por esta se encuentran
en entornos públicos no propietarios. Esta modalidad es adecuada para acceder a herramientas de
colaboración, ofimáticas o de almacenamiento.
Características:
• Abiertas al público y son propiedad de un proveedor de Cloud Computing que,

adicionalmente, se encarga de gestionarlas.
• Todas las garantías de privacidad, seguridad y disponibilidad, así como las penalizaciones
por incumplimiento, deben estar expresadas en el contrato de servicio.
• Proporciona ahorros en costes y gran flexibilidad para hacer frente a los picos de demanda
por Internet a cambio de menores niveles de seguridad de los datos de los que hace uso.
Como ventajas, las nubes públicas ofrecen una alta capacidad de procesamiento y
almacenamiento de forma externa, evitando inversiones en equipos y mantenimiento de forma
local en la empresa. Los procesos de gestión, seguridad de datos y actualización del software y
hardware se realizan por parte del proveedor y de forma transparente al uso diario por parte del
cliente. Cualquier tipo de incidencia o desastre local no afecta a la infraestructura o datos
almacenados en la nube pública. El escalado y flexibilidad de las infraestructuras se realizan en el
proveedor a unos costes muy bajos.
Como desventajas tenemos la dependencia de los servicios en línea y el acceso a través de

Internet. Las empresas deben tener unas buenas infraestructuras de conectividad para evitar
problemas de conexión. Hay que estudiar bien la integración de trabajar en la nube con los
sistemas propietarios que deben coexistir al mismo tiempo. Hay que prever que el proveedor nos
pueda garantizar la obtención de todos los datos almacenados en la nube para poder disponer de
ellos en el menor tiempo posible.
3.2. Nubes privadas
Las nubes privadas son aquellas en que tanto los servicios como los datos son propiedad de una
organización. Las infraestructuras pueden encontrarse en las instalaciones de la organización,
dificultando su mantenimiento si se hace a través de un proveedor. Los servicios y/o las
infraestructuras pueden ser gestionados por la propia organización o bien por un tercero. Las
nubes privadas proporcionan una mayor seguridad y privacidad de los datos. La mayoría de
organizaciones que proporcionan servicios en la nube suelen tener una nube privada.
Las ventajas de las nubes privadas es la localización dentro de la propia empresa. Tanto los datos
como la infraestructura están integrados con las de la propia empresa, lo que implica una gestión
localizada y personalizada y fácil integración de los servicios y datos de la nube en sistemas
propietarios de la empresa.
Como desventajas la empresa debe realizar una inversión inicial en montar la infraestructura
hardware, sistemas de seguridad, backup, ancho de banda. Más gastos de personal y de
mantenimiento de todas las infraestructuras hardware y software. Las escalabilidad de la nube
privada puede verse mermada por los altos costes de inversión. La seguridad puede verse
comprometida por la propia vulnerabilidad de un centro de datos interno, no especializado.
3.3. Nubes Híbridas
Las nubes híbridas resultan de la combinación de dos o más nubes de diferentes tipos. Por
ejemplo, cuando una empresa tiene servicios dispuestos en su red privada pero también utiliza una
nube pública.
Las nubes híbridas combinan los servicios locales con los ofrecidos externamente por una nube
pública. Las empresas puede dividir sus servicios para mantener unos en modo local y privado
dentro de la empresa y aprovechar otros servicios que la nube pública le ofrece y que pueden ser
aprovechados donde se necesiten. La nube híbrida es un paso intermedio para pasar o crear
nuevos servicios en la nube pública.
Por ejemplo es muy común que muchas empresas utilicen servicios de almacenamiento en la nube
pública para almacenar ciertos datos que considere que necesita tener de forma accesible
externamente.
Las ventajas de la nube híbrida es que la inversión inicial es más moderada y permite realizar un
aumento progresivo de la utilización de los servicios de la nube pública según necesidades. Para
empresas con aumento de necesidades puntuales estas nubes son las que les permiten obtener
servicios bajo demanda combinándolos con la nube privada.
Una entidad que opte por esta solución puede beneficiarse de las ventajas que el resto de tipos
nubes tenían por separado. Por ejemplo, se dispone de una gran flexibilidad a la hora de adquirir
servicios, pero además es posible tener control sobre ellos.
3.4. Nubes de Comunidad
Las nubes de comunidad son aquellas nubes donde los servicios se comparten en una
comunidad cerrada de entidades que tienen los mismos objetivos, de manera que colaboran entre
ellas. En este caso la nube es gestionada y administrada por una o más entidades de la
comunidad.
Características:
• Ofrecen una infraestructura compartida por varias organizaciones. Muy adecuadas para
Administraciones públicas ya que pueden compartir multitud de servicios.
• Gestionadas por las propias organizaciones o un tercero.
• Alojadas en las instalaciones de los usuarios o no.
4. Tipos de Servicio en el Cloud Computing
Igual que existe diferentes tipos de nubes podemos establecer diferentes tipos de servicio dentro
del cloud computing de acuerdo al grado de uso de los componentes Software/Hardware y del tipo
de gestión de esto ya sea propia o realizada por terceros. Las necesidades que el cliente/usuario
tenga del cloud marcarán el uso que se haga de este.
Los tres tipos principales son:
• Software as a Service (SaaS).
• Platform as a Service (PaaS).
• Infrastructure as a Service (IaaS).
4.1. Software as a Service (Saas)
Todos aquellos servicios en la nube, en los que el usuario o corporación accede directamente a
través de un “thin client”, como puede ser un navegador web, sin conocimiento de la infraestructura
subyacente a niveles de capas de negocio, capas de servidor. Toda la parte técnica queda en
manos del Partner que la ha desplegado, asumiendo este toda la complejidad de su instalación, su
mantenimiento y además de soportar también la seguridad de la información.
Se trata de la opción más sencilla de contratar, ya que no requiere conocimientos técnicos, pero en
muchas empresas y organismos públicos se recela de esta alternativa ya que implica
necesariamente perder el control de todo el ciclo de vida de la información, con lo que puede que
los requisitos y protocolos de seguridad y privacidad del SaaS no se ajusten a determinados datos
de especial sensibilidad para las empresas. Por ello, hoy por hoy, el SaaS suele usarse
principalmente para servicios de correo electrónico, plataformas colaborativas y también en
algunas aplicaciones de negocio como el CRM (Customer Relationship Management).
4.2. Platform as a Service (Paas)
Un nivel por debajo del Saas nos encontramos con el Platform as a Service. Es un modelo de
servicio en el que la corporación puede desplegar aplicaciones o desarrollos propios o ajenos sin
tener que realizar un desembolso por los recursos hardware de proceso y de almacenamiento que
requieren dichos despliegues ya que estos corren a cargo del proveedor de servicios que tengan
contratado. De este modo, los desarrolladores pueden construir sus aplicaciones a su gusto, con
sus requisitos específicos de funcionamiento y seguridad, pero desligándose por completo de la
instalación y configuración del hardware que las sostiene.
El proveedor de servicios proporciona en este caso una plataforma virtual que engloba los recursos
de infraestructura, sistemas operativos, middleware y runtimes.
Ejemplos: MS Windows Azure, Google App Engine, Amazon Web Services (AWS)
4.3. Infrastructure as a Service (Iaas)
La infraestructura como servicio (IaaS) proporciona posibilidades a las organizaciones que

necesiten adaptar sus recursos de procesamiento y almacenamiento de una manera elástica,
eficiente y que aumenta o disminuye bajo demanda.
Se desacopla las cargas de trabajo del hardware físico y su consolidación sobre servidores. En
otras palabras, se construye una solución que comprenda los “Fabrics” (tejidos, estructuras) de red
y almacenamiento y el conjunto de elementos de cómputo incluidos en los servidores, con su capa
de virtualización por encima, para ofrecerla a clientes internos y/o externos.
En ocasiones se refieren a IaaS como HaaS (Hardware as a Service). Como ejemplos de este tipo
de servicios podemos mencionar GoGrid y Amazon EC2 (Elastic Compute Cloud).
5. Almacenamiento en la Nube
El almacenamiento en la nube o “cloud storage” es una forma sencilla, escalable, accesible y más
o menos segura de almacenar y/o compartir información a través de internet.
El almacenamiento es uno de los modelos de servicio más utilizados, tanto por las organizaciones
como por particulares, dentro de los modelos de servicios que se proporcionan a través el cloud
computing a través de internet.
El almacenamiento en la nube elimina los costos de adquisición y administración que conllevan la

compra y el mantenimiento de su propia infraestructura de almacenamiento, incrementa la agilidad,
proporciona escala global y permite el acceso a los datos "desde cualquier lugar y en cualquier
momento".
Se puede definir el almacenamiento en la nube como “el modelo de servicio en el cual los datos
generados por un sistema de cómputo se almacenan, se administran, y se respaldan de forma
remota, típicamente en servidores que están en la nube y que son administrados por un proveedor
del servicio. Estos datos se ponen a disposición de los usuarios a través de una red, como lo es
Internet haciendo uso de una variedad de protocolos como pueden ser REST, SOAP, WSDL,
UDDI, SNMP, CIFS, SSL, TLS, AES y HTTP, HTTPS, FTP.
5.1. Tipos de Almacenamiento en la nube
Dependiendo del tipo de nube en el que se realice, se definen tipos de servicio de almacenamiento
en la nube.
Público. El almacenamiento se lleva a cabo en una cloud pública.
Características:
• Poco control administrativo
• Acceso por autorización explícita o implícita
• Mismo espacio de almacenamiento físico sobre una capa virtual.
• Acceso Externo y sólo accesible con conexión a internet.
• Bajo costo y bajo mantenimiento.
Privado. Almacenamiento en la nube privada. Es utilizado para cubrir las necesidades de una
organización.
Características:
• Características: dos formatos de presentación on-premise (en la misma oficina o casa) o

externo.
• El más utilizado por empresas no tanto por personas individuales.
• Control administrativo por parte de la empresa.
• Autoservicio
• Escalabilidad
Híbrido. Los sistemas de almacenamiento en nubes híbridas ofrecen, como su nombre sugiere,
una combinación de almacenamiento en nubes públicas y privadas.
Características:
• El usuario del servicio puede personalizar las funciones y las aplicaciones que se adaptan
mejor a sus necesidades, así como los recursos que se utilizan.
Un ejemplo típico de este tipo de servicio es que se configure de tal forma que los datos más
importantes se almacenen en un sistema de almacenamiento en la nube privada, mientras que los
datos menos importantes se pueden almacenar en una nube pública con acceso disponible por
una gran cantidad de personas a distancia.
Referencias bibliográficas
(1) Greg F. Pfister. In Search of Clusters. 1998.
(2) Peter Mell and Timothy Grance. The NIST definition of cloud computing.Special Publication 800-
145, 2011.
(4) Above the Clouds: A Berkeley View of Cloud Computing, UCB/EECS-2009-28. Technical report,
2009.
(5) Ian Marriot. Gartners 30 Leading Locations for Oshore Services. Gartner, 2009.
(6) Forecast: Public Cloud Services, Worldwide and Regions, Industry Sectors,2010-2015.
Technical report, 2011.
(7) Google Cloud Platform. https://cloud.google.com/
(8) Amazon Web Services. http://aws.amazon.com/es/
(9) Microsoft Azure. http://azure.microsoft.com/es-es/
(10) Docker. https://www.docker.com/.
(11) Trabajo de Fin de Grado Computación en la nube. Oportunidades, retos y caso de estudio.
Sara Báez García
(12) Bonet, S., González, F., Oltra, R., Conchado, A., Guzmán, A., Cebrián, C. 2012. Análisis de la
oferta y la demanda de los servicios Cloud
Tema 22. Virtualización de sistemas. Servidores
de datos y de aplicaciones. Sistemas de
almacenamiento
José Ramón Gómez García

Colegiado 0525
La virtualización consiste en el proceso de abstracción mediante software de los

recursos físicos de uno o varios servidores, para dar lugar a una serie de recursos
lógicos, también llamado hardware virtual, de forma que una sola máquina física,
puede dar lugar a varias máquinas lógicas, cada una con sus propios recursos y
sistema operativo. Entre los diferentes tipos de sistemas a virtualizar, encontramos
servidores completos, sistemas de almacenamiento, sistemas operativos y
aplicaciones.
Este capítulo pretende trasmitir las ventajas de la virtualización a diferentes niveles,

así como las diferentes tecnologías existentes.
1. Qué es la virtualización
El termino virtualización fue acuñado por primera vez en los años 1960 por IBM, con la creación
del mainframe IBM/S360, la primera máquina diseñada específicamente para ser virtualizada. Este
concepto surge de la necesidad de reducir costos, para lo cual se ofrece servicio a varios
departamentos de la empresa en sistemas aislados, dentro de un único computador físico. Como
novedad, esta máquina permitía correr múltiples sistemas operativos, en un único computador. La
capacidad de virtualización que marcó un estándar que fue continuado por las series sucesoras,
como la S370 y siguientes.
La abstracción entre los recursos de la máquina física y el sistema operativo de la máquina virtual,
es llevada a cabo por un software denominado hipervisor (Hypervisor en inglés) o VMM (virtual
machine monitor). La principal característica de este software su estabilidad y robustez, aislando
cada uno de los sistemas operativos instalados en las diferentes máquinas virtuales, de forma de
los fallos en cada uno de ellos no afecten al resto.
Durante los años 1960 y 1970, fueron unos sistemas muy populares, decayendo su popularidad
hasta casi desaparecer durante los años 1980.
A finales de los años 1990, surge de nuevo la necesidad de consolidar servidores y simplificar las
tareas de administración de los mismos, al tiempo que empieza a aparecer el término virtualización
fuera del ámbito de los servidores, con la llegada de uno de los primeros hipervisores compatibles
con la arquitectura x86, desarrollado por VMWare lo que permite crear máquinas virtuales en PCs.
Además, se traslada este concepto a otros subsistemas, tales como el sistema operativo, las
aplicaciones o el almacenamiento.
1.1. Características de un sistema virtualizado
La virtualización es una técnica que consiste en, la abstracción mediante software de un recurso
físico, en un recurso virtual. Es aplicable a servidores, sistemas operativos, escritorios,
aplicaciones y redes, entre otros.
Entre las principales ventajas de un sistema virtualizado, se encuentran las siguientes:
• Independencia: Los recursos virtuales son totalmente independientes entre sí, además de
con los recursos físicos. Por ejemplo, en el ámbito de los servidores, un error en la propia
máquina virtual o sus aplicaciones, no afecta al resto de máquinas que corre el Hipervisor,
que siguen funcionando con total normalidad.
Virtualización de sistemas
• Escalabilidad: Los sistemas virtualizados son fácilmente escalables, ya que permiten

añadir más recursos físicos, como por ejemplo, nuevos servidores, cuyos recursos pueden
ser usados por el sistema virtualizado.
• Alta disponibilidad: En un sistema virtualizado con varios hosts físicos, ante un error en uno
de ellos, las máquinas virtuales que éste ejecuta pasan a ser ejecutadas por los otros
servidores, de forma que no se produce pérdida de servicio.
• Flexibilidad: A la hora de definir una máquina virtual, no es necesario la búsqueda de

hardware concreto. El sistema nos permitirá asignar de forma flexible número de
procesadores, cantidad de memoria y espacio en disco de forma flexible. Además, estos
parámetros, podrán ser modificados mediante el Hipervisor. De esta forma, se facilitan las
tareas de mantenimiento de la infraestructura.
• Seguridad: Al tratarse de sistemas operativos independientes, cada invitado, así como el

anfitrión gestiona sus propios usuarios y accesos. De esta forma, los problemas de
seguridad de una máquina no afectan al resto.
• Agilidad: La virtualización nos permite tener definidas plantillas de máquinas virtuales, o

generar otras máquinas mediante el clonado de las ya existentes, con lo cual, el alta o baja
de servidores se reduce a una cuestión de minutos.
• Protección del medio ambiente y ahorro de costes: La virtualización, supone un mejor

aprovechamiento de los recursos hardware, lo que se traduce en una reducción del número
de servidores físicos necesarios para un mismo servicio, y por tanto, menos necesidades
de refrigeración, todo lo cual se traduce en un menor uso de energía, y por tanto, de
costes.
No obstante, no todo son ventajas. Por norma general, y en función de la tecnología de

virtualización utilizada, una misma aplicación suele obtener mejor rendimiento en un sistema sin
virtualizar, que en un sistema virtualizado.
Además, la capacidad de creación de recursos virtuales, viene limitada por los recursos hardware
del servidor físico. Por ejemplo, si necesitamos crear 4 máquinas virtuales con 8 GB de memoria
RAM, necesitaremos un servidor físico que al menos tenga 32 GB (8GBx4), a lo cual hemos de
añadir como requerimiento la parte de memoria que usa el propio Hipervisor. Lo mismo ocurre con
el almacenamiento.
2. Tipos de virtualización
Es posible definir diferentes tipos de virtualización en función del recurso a virtualizar, siendo los
siguientes los más usados actualmente:
• Virtualización de servidores, Hipervisor.
• Virtualización de sistema operativo.
• Virtualización de escritorio.
• Virtualización de aplicaciones.
• Virtualización del almacenamiento.
En los siguientes puntos del capítulo se profundiza en cada uno de ellos.
2.1. Virtualización de servidores
2.1.1. Virtualización completa
La virtualización completa de servidores o virtualización hardware consiste en la utilización de un

software, denominado Hypervisor, capaz de crear y gestionar máquinas virtuales que emulan
varios hosts aislados, en un único servidor físico. Es habitual el uso del término host o anfitrión
para hacer referencia a la máquina donde se instala el hipervisor, y el término invitado o guest para
referirse a las distintas máquinas virtuales generadas por el software de virtualización.
Apps Apps Apps Apps
S.O. S.O. S.O. S.O.
Invitado 1 Invitado 2 Invitado 3 Invitado n
Hipervisor
Hardware físico (anfitrión)
Figura 1: Esquema de un servidor virtualizado
El resultado que obtenemos es el de diferentes servidores virtuales independientes, que se

ejecutan físicamente en un único servidor físico. Estos servidores virtuales, inicialmente
introdujeron una merma en las prestaciones respecto a las máquinas físicas, por la complejidad de
convertir las operaciones del hardware virtual a operaciones del hardware físico. Sin embargo, con
la llegada de las tecnologías Intel-VT y AMD-V (creadas en los años 2005 y 2006 respectivamente)
que ofrecen soporte a virtualización, esta merma de recursos se reduce llegando a ser
prácticamente nula.
Generalmente, la máquina virtual se compone de un fichero de configuración que define los

parámetros de la máquina, y un fichero denominado datastore, de tamaño importante, que simula
el disco duro de la máquina virtual.
Aunque es posible virtualizar mediante el uso de los discos locales del servidor físico, en entornos
virtualizados con gran demanda es habitual que los datastores se guarden en sistemas de
almacenamiento externo con la finalidad de aumentar su capacidad. Para ello, es habitual el uso
de redes de almacenamiento de datos SAN, conectados a los servidores por redes de fibra óptica
dedicada, de forma que el rendimiento de acceso a los datos es similar al acceso a los discos
locales.
2.1.2. Paravirtualización
El concepto de paravirtualización surge de la necesidad de dotar de un mayor rendimiento a los

sistemas virtualizados, ya que al depender todas las operaciones de los sistemas invitados del
Hipervisor y el hardware virtualizado, se produce una pérdida de rendimiento.
El enfoque de la paravirtualización es muy similar al de la virtualización completa, pero en los

invitados se hace uso de sistemas operativos adaptados, con modificaciones en el núcleo, que
permite realizar llamadas directas al hardware de la máquina física, haciendo uso del API del
Hipervisor. Las operaciones son enviadas directamente al hardware físico, en lugar de ser
ejecutadas en la capa de virtualización. Como principal ventaja, obtenemos un mayor rendimiento
de los sistemas invitados, respecto a la virtualización completa.
2.1.3. Principales softwares de virtualización
2.1.3.1. VMWare ESX
VMWare ESX es un Hipervisor desarrollado por VMWare para virtualización de servidores. No es

necesario el uso de ningún sistema operativo, puesto que es el propio software el que se instala
sobre la máquina física. Toma como base Red Hat Entreprise Linux, a cuyo kernel añade los
componentes de virtualización y el propio Hipervisor. El resultado, es un sistema con apariencia
Linux, tanto en arranque como en funcionamiento, pero con funciones de virtualización.
Para ello, VMWare provee una herramienta denominada vSphere Client, una herramienta gráfica
para administrar y monitorizar el entorno virtualizado bajo ESX. En las últimas versiones, también
está disponible una versión web de esta herramienta denominada vSphere Web Client. La
herramienta sólo está disponible para ser ejecutada en sistemas operativos Windows.
2.1.3.2. Citrix XenServer
XenServer es una herramienta de virtualización en código abierto. Fue desarrollado por la

Universidad de Cambridge como solución de paravirtualización, que permitía correr determinados
sistemas operativos con el kernel adaptado, principalmente sistemas de código abierto como Linux,
FreeBSD o NetBSD.
Más tarde, tanto Intel como AMD contribuyeron a dotar Xen de apoyo para sus tecnologías Intel-VT
y AMD-v, de forma que pasó a ofrecer soporte para virtualización completa. Tras ello, era posible
instalar cualquier sistema operativo sin modificar, incluidas diferentes ediciones de Windows.
En el año 2007, Xen fue comprado por la empresa Citrix, que actualmente ofrece a los usuarios su
versión de Xen empresarial, así como una de uso libre, con determinadas restricciones de uso.
Para la administración de las máquinas virtuales, se usa el software XenCenter, desarrollado por
Citrix, que permite administrar de forma visual el servidor virtualizado. El interfaz de administración
Citrix XenCenter únicamente está disponible para ser ejecutado en sistemas operativos Windows.
No obstante, existen otras herramientas gráficas para administración de entornos virtualizados con
Xen Server desarrolladas en código abierto y que permiten ser instaladas en sistemas operativos
Linux. Un ejemplo sería OpenXenManager.
2.1.3.3. Hyper-V
Hyper-V es una herramienta de Microsoft para virtualización bajo sistemas Windows. Fue lanzada
en 2008 como parte del sistema operativo Windows Server 2008. También está disponible en las
ediciones Pro y Entreprise de Windows 8 y Windows 10. Además, existe un paquete Hiper-V
Server, para su adquisición individual que contiene únicamente el Hipervisor de Microsoft.
2.1.4. Funciones comunes en la virtualización
Es habitual hablar de operaciones en caliente de máquinas virtuales. El término “en caliente”, hace
referencia a poder realizar operaciones sobre las máquinas virtuales sin necesidad de apagar las
mismas, con el resultado de que el servicio no se verá interrumpido. Estas operaciones resultan
especialmente útiles cuando la organización dispone de un pool de servidores virtualizado.
Básicamente, se trata de varios equipos físicos, cada uno de ellos con su hipervisor instalado, que
son capaces de repartir la carga entre ellos. Para ello, es habitual que los datastores estén
almacenados en una red de almacenamiento SAN, de forma que son accesibles por los distintos
servidores del pool.
Una de las operaciones habituales, es la migración de máquinas virtuales entre servidores físicos.
Esta operación puede ser necesaria por varios motivos: problemas hardware en el servidor que
corre las máquinas, necesidad de reemplazo del servidor por uno nuevo, o bien, reparto de las
máquinas en diferentes servidores físicos por necesidades de carga o del servicio. La mayor parte
de sistemas nos permite realizar estos cambios sin interrumpir el servicio que prestan.
Otra de las virtudes de la virtualización es distribuir las cargas de trabajo entre los servidores en
tiempo real. La distribución de carga en sistemas virtualizados permite, en tiempo real, encender o
apagar máquinas virtuales en función de la demanda actual de carga. De esta forma, podemos
tener un entorno bastante conservador en cuanto a recursos, pero que ante un pico de carga
pueda dar respuesta.
2.2. Virtualización de sistemas operativos
La virtualización de sistemas operativos es una solución que permite ejecutar un sistema operativo
dentro de otro sistema operativo, como si se tratase de un programa más. Nos referimos a este
software como hipervisor de tipo 2. La diferencia con el hipervisor del apartado anterior
(comúnmente referenciado como tipo 1), reside que en no necesita un sistema operativo para ser
ejecutado. Para ello, el hipervisor toma parte de los recursos al sistema operativo anfitrión para
permitir ejecutar el sistema operativo invitado. De forma similar a la virtualización de servidores, la
virtualización de sistema operativo se compone por un fichero de configuración con los parámetros
de la máquina, y un fichero para el disco duro o datastore. El resultado, es una ventana de
aplicación en el sistema operativo anfitrión, en cuyo interior aparece el sistema operativo invitado.
Apps Apps Otro software
S.O. S.O.
Invitado 1 Invitado 2
Hipervisor tipo 2
Sistema operativo (anfitrión)
Hardware físico (anfitrión)
Figura 2: Virtualización de sistema operativo
Resulta especialmente útil en equipos de usuario para compartir diferentes sistemas operativos, ya
sea por la necesidad de disponer de diferentes entornos Windows y Linux, o incluso, virtualizar
alguna edición más antigua de Windows para poder usar determinado software no compatible con
ediciones más modernas del sistema operativo.
También suele ser usado para testear nuevo software de forma sencilla, sin tener que disponer de
un equipo hardware dedicado. El test de un nuevo sistema operativo en fase beta, requiere poco
más que un par de minutos para la creación de la máquina virtual, y el tiempo de instalación.
Incluso, es habitual que los propios fabricantes del software habiliten una serie de imágenes
virtuales con el sistema operativo, con no es necesario instalarlo. En estos casos basta con
descargar la imagen e importarla en el hipervisor.
Las principales empresas de virtualización disponen de software para la virtualización del sistema
operativo, siendo los siguientes los más usados:
• Oracle VirtualBox.
• VMWare Server.
• Parallels.
• Microsoft VirtualPC.
2.3. Virtualización de escritorio
La virtualización de escritorios o VDI es una solución que permite independizar el escritorio que
utiliza el usuario (o el sistema operativo en su totalidad) del hardware que usa para su acceso. El
escritorio se ejecuta remotamente en un servidor, y el disco local que utiliza también se encuentra
ubicado en el servidor remoto. La experiencia que uso que obtiene el usuario, es la de tener el
sistema operativo instalado en su propio equipo. Para su acceso, debe existir conexión de red
entre el hardware que utiliza el usuario y el servidor remoto.
Con esta tecnología, el usuario tiene acceso a su escritorio independientemente del hardware
usado, y su ubicación, siempre que exista conexión de red entre el dispositivo y el servidor.
Incluso, se independiza del tipo de hardware usado, ya que es posible usar un PC tradicional, así
como un portátil o un dispositivo móvil. También existe independencia entre el tipo de escritorio
virtualizado, y el sistema operativo del equipo cliente. Es posible acceder a un escritorio Windows
usando cualquier sistema operativo.
A nivel de negocio, este modelo aporta mucha flexibilidad, tanto para los usuarios, como para los
administradores, además de ahorro en hardware importante, como se verá más adelante.
Por una parte, se independiza el puesto de trabajo del usuario que lo vaya a usar. Un ejemplo
sencillo sería un mismo puesto de trabajo, que se utiliza por dos usuarios, a media jornada. Por la
mañana, el primer usuario accede con el hardware del puesto a su escritorio personalizado, con
sus datos y aplicaciones. Al terminar la jornada, cierra su sesión, y el usuario de la tarde, utiliza el
mismo hardware para acceder a su sesión de usuario, que puede ser totalmente diferente. Esta
misma ventaja la tenemos presente en caso de necesitar realizar rotaciones de ubicación en la
oficina por diferentes motivos.
De cara a la administración, el alta y baja de puestos de trabajo se realiza en cuestión de minutos.

Casi bastaría con dar de alta el usuario en el servidor y asignar un perfil o rol, y ya tendría el
puesto configurado para trabajar desde cualquier puesto disponible.
En el apartado hardware, como ya se habrá deducido, los requisitos son menos estrictos ya que la
mayor parte del trabajo de procesamiento se realiza directamente en el servidor. Como resultado,
se alarga el ciclo de vida útil del hardware. Además, es posible recurrir al uso de clientes ligeros
reduciendo los costes de adquisición. Por otro lado, las averías no suponen largos procesos de
reinstalación del equipo, con lo que se reducen los tiempos. Basta con reemplazar el hardware
afectado, y el usuario tiene su puesto disponible tal y como estaba antes de la avería.
2.4. Virtualización de aplicaciones
Si subimos un nivel más, llegamos al nivel de aplicación. A estas alturas del capítulo, poco más se
puede añadir del concepto de virtualización, simplemente, enfocarlo en el nivel de aplicación.
Básicamente, consiste en tener un servidor en el que tenemos instaladas unas aplicaciones, y éste
ofrece la posibilidad de que sean ejecutadas de forma virtual desde otros sistemas.
Su principal objetivo es independizar las aplicaciones del entorno donde se ejecutan, de forma que
se eliminan los problemas de incompatibilidad de librerías, o con otras aplicaciones e incluso el
propio sistema operativo. Para ello, el software de virtualización crea un entorno de ejecución, con
los componentes necesarios para cada instancia de aplicación, que es presentado en el cliente.
Al igual que en la virtualización de escritorios, el procesamiento de la misma se realiza en el

servidor. Sin embargo, la experiencia de uso que obtiene el usuario es de estar ejecutándola de
forma local a su sistema operativo. En este caso, el sistema operativo sí que se ejecuta en el
equipo local. Las ventajas son similares a las comentadas en el apartado de virtualización de
escritorio. Principalmente, la administración, ya que para dar acceso a una aplicación a múltiples
usuarios, se centraliza la operación en el servidor. También es importante el hecho de que se
independiza la aplicación del sistema operativo que usa el cliente.
Aunque la aplicación se procesa en un servidor remoto, el usuario tiene disponible los recursos
locales, como carpetas e impresoras, para su interacción con la aplicación.
Entre los principales softwares de virtualización de aplicaciones, se encuentran:
• Citrix XenApp.
• Microsoft App-V.
• VMWare Horizon.
2.5. Dispositivos de almacenamiento. Virtualización
La definición es muy similar a lo visto en el apartado de servidores, pero en este caso, el único
recurso a virtualizar es el almacenamiento. Es decir, consiste en definir unidades lógicas de
almacenamiento (almacenamiento virtual) abstrayendo las unidades lógicas que lo forman. En
general, suele ser usado para crear grandes unidades de almacenamiento a partir de la unión de
unidades físicas más pequeñas, que aparecerán como una sola unidad lógica de mayor tamaño.
También puede ser usado para dividir una unidad grande en varias más pequeñas, pero no suele
ser lo habitual. Existen otros mecanismos para este fin.
La virtualización del almacenamiento, mantiene todas las propiedades asociadas a la virtualización

comentadas en puntos anteriores.
Para su implementación, se suele usar una SAN (red de área de almacenamiento), aunque
también puede ser implementado mediante dispositivos NAS en entornos con requisitos menos
estrictos en cuanto a rendimiento y menor presupuesto.
Las redes de área de almacenamiento SAN, son redes dedicadas exclusivamente al

almacenamiento, y se componen de los elementos habituales de una red:
• Dispositivos de almacenamiento, como cabina de discos.
• Medio de trasmisión de alta velocidad. Generalmente, fibra óptica.
• Switch dedicado de alto rendimiento.
El uso de esta red es exclusivo para acceso a datos desde los servidores con acceso a la SAN.
Para ello, los servidores tienen una interfaz de red dedicada a acceso a la SAN, además de la
conexión habitual a la LAN de la empresa. Los protocolos más habituales para el acceso son FC o
iSCSI. El primero de ellos aporta una mayor velocidad de acceso a datos, mientras que el segundo
tiene una implementación más económica.
Las principales ventajas de las redes de área de almacenamiento son:
• Ampliación casi ilimitada. Basta con añadir más dispositivos de almacenamiento a la red
para aumentar su capacidad.
• Alta disponibilidad de datos.
• Permite compartir datos entre servidores de forma muy eficiente.
El principal inconveniente de las soluciones SAN es su coste de implementación. Frente a ellas,

existe una solución más económica. El uso de dispositivos NAS. Frente a la red dedicada de las
soluciones SAN, el acceso a dispositivos NAS se realiza mediante la LAN de la empresa, con el
uso de peticiones TCP/IP. Para ello, emplea protocolos como CIFS o NFS. Por ello, el rendimiento
de una solución NAS es mucho menor al obtenido con una solución SAN.
La principal diferencia entre ambos sistemas reside en la forma de acceder a los datos. El acceso
a dispositivos NAS se realiza mediante la red local (LAN), mediante peticiones TCP/IP a través de
protocolos como CIFS o NFS. Sin embargo, el acceso a dispositivos SAN se realizan directamente
por el sistema operativo con protocolos de bajo nivel, de forma similar a los accesos a discos
locales al equipo. Para ello, hacen uso de una red dedicada de alta velocidad, fibra óptica
principalmente.
2.5.1. Configuración de RAIDs
El acrónimo RAID proviene del inglés Redundant Array of Independent Disks y hace referencia a
un sistema de almacenamiento que utiliza múltiples unidades de almacenamiento, entre las que se
distribuyen o replican los datos, en función de la configuración realizada. Un RAID muestra todas
las unidades físicas como una sola unidad lógica. Esta configuración se suele realizar mediante
hardware, siempre que el chip de la placa base lo soporte o se disponga de una controladora raid
adecuada. En su defecto, la mayoría de sistemas operativos, permiten realizar configuraciones
RAID software, pero en este caso, su rendimiento suele ser menor. Se recomienda el uso de
unidades de igual tamaño, ya que en caso contrario, en las unidades de menor tamaño, sólo se
utiliza el equivalente a la unidad de menor tamaño.
Entre las principales ventajas del uso de configuraciones RAID, aunque depende su grado en
función de la configuración realizada, son las siguientes:
• Mayor integridad de datos.
• Incrementa la toleracia a fallos.
• Mayor rendimiento.
Los niveles RAID estándar son: RAID 0, RAID 1 y RAID 5. No obstante, existen otras variantes de
configuraciones RAID.
2.5.1.1. RAID 0
RAID 0 o volumen dividido, es una configuración de dos o más discos, en la que se distribuyen los
ficheros sin realizar redundancia de datos. Su principal ventaja es el rendimiento de acceso a los
datos, ya que puede realizar simultáneamente operaciones de lectura/escritura sobre diferentes
ficheros en las diferentes unidades. Cada fichero, se encuentra almacenado en una única unidad y
no existe redundancia sobre él. Por ello, no ofrece tolerancia a fallos, ya que un fallo en una de las
unidades provoca pérdida de los datos almacenados en la misma.
RAID 0
A1 A2
A3 A4
A5 A6
A7 A8
Disco 1 Disco 2
Figura 3: Configuración RAID 0
Como ejemplo, si se realiza un RAID 0 sobre dos unidades, cada una de ellas con una capacidad
de 1 TB, el resultado obtenido es una unidad lógica de 2TB, sin tolerancia a fallos que podrá
alcanzar tasas de lectura/escritura del doble de las unidades que lo forman.
2.5.1.2. RAID 1
La configuración RAID 1, o en espejo, crea una copia de los datos en dos o más discos (tantas
unidades como formen el RAID). Cada uno de los discos que forman el RAID 1, es una copia
exacta del resto. En términos de almacenamiento, la capacidad de un RAID 1 es equivalente a la
capacidad del menor de los discos que lo forman. En cuanto a rendimiento, éste aumenta en las
operaciones de lectura, ya que permite realizar distintas operaciones de lectura en cada una de las
unidades. Sin embargo, las operaciones de escritura, se han de realizar simultáneamente en todas
las unidades, por lo que su rendimiento se mantiene respecto a las unidades que lo forman.
Su principal ventaja, es la tolerancia a fallos, puesto que ante un error en alguna de las unidades
los datos continúan disponibles en el resto. Para recuperar el sistema, basta con reemplazar la
unidad dañada. También ofrece facilidades de administración, ya que es posible marcar alguna de
las unidades como inactiva, para extraerla y realizar copias de seguridad u otras tareas sobre la
misma.
Su principal inconveniente es el coste por megabyte que se multiplica por el número de unidades
que formen el RAID1.
RAID 1
A1 A1
A2 A2
A3 A3
A4 A4
Disco 1 Disco 2
Si se toman dos unidades de 1 TB de capacidad, configuradas en RAID 1, el resultado es una

unidad lógica de 1 TB de capacidad, con tolerancia a fallos en caso de fallo de uno de los discos.
En cuanto a tasas de lectura/escritura, las tasas de lectura pueden ser hasta el doble de rápidas
que en las unidades originales. Sin embargo, la tasa de escritura se mantiene, puesto que se ha de
realizar la escritura en ambas unidades.
2.5.1.3. RAID 5
La configuración RAID 5, o distribuido con paridad, consiste en distribuir la información de paridad

entre todos los discos que forman el RAID. Necesita un mínimo de 3 discos para ser
implementado. En las operaciones de escritura, se escriben tres bloques, cada uno en una unidad.
Dos de los bloques contienen la información original, y el tercer bloque contiene la información de
paridad. Los datos de paridad del RAID se encuentran distribuidos en las 3 unidades.
Entre sus principales ventajas, su aprovechamiento del almacenamiento es más óptimo que en un
RAID 1. Además, la tasa de escritura es más rápida en RAID 5 que en RAID 1. Sin embargo, un
RAID 1 ofrece una mejor tasa de lectura.
En lo referente a tolerancia a fallos, es posible recuperar el sistema si existe fallo en alguna de las
unidades, puesto que siempre se dispondrá en las otras dos, bien de dos bloques de información
original, o bien de un bloque de información más otro de paridad.
Para conseguirlo, se dividen los datos en bloques de dos en dos. Al escribirlo grabaremos tres
bloques dos con la información original y otro con una que se obtiene al combinarlos. Esta
información se graba alternativamente en los discos. En caso de que caiga uno siempre puedes
recuperar la información ya que cualquier disco es función de los otros dos.
RAID 5
A1 A2 Ap
Bp A1 B2
C1 Cp C3
D1 D2 Dp
Disco 1 Disco 2 Disco 3
En el caso de RAID 5, como se ha comentado se requiere un mínimo de 3 unidades. El resultado

de configurar tres unidades de 1 TB de capacidad, configuradas en RAID 5, el resultado obtenido
es una unidad lógica de 2 TB, con tolerancia a fallos sobre una unidad de las que forman el RAID.
Respecto a tasas de lectura/escritura, se obtienen tasas de lectura hasta doble de velocidad de
cada una de las unidades. La tasa de escritura se mantiene.
Si se aumenta el número de unidades que forman el RAID5, el aprovechamiento del espacio es

mayor, así como la tasa de lectura obtenida. Como ejemplo, un RAID 5 configurado sobre 6
unidades de 1TB, obtiene una unidad lógica con una capacidad de 5 TB, con tasas de lectura
hasta 5 veces más rápidas que cada una de las unidades que lo forman. La tolerancia a fallos,
sigue siendo sólo de fallo en una de las unidades que forman el RAID. El motivo, es que
indistintamente del número de unidades que formen el RAID 5, el espacio dedicado a información
de paridad, siempre es el equivalente a una de las unidades.
(1) Romo Gutiérrez, Jaime (2011). Consolidación de Servidores por medio de la Virtualización.
EAE Editorial Academia Española.
(2) Troy, Ryan (2010). VMware. Anaya Multimedia/O’Reilly.
(3) Chaganti, Prabhakar (2007). Xen Virtualization: A Practical Handbook. Ed. Packt Publishing.
(4) RAID - https://es.wikipedia.org/wiki/RAID
Tema 23. Tratamiento de información multimedia
Joan Ferre i Ferre

Colegiado 0874
El tratamiento de información multimedia exigirá antes de nada de asegurar la

decidibilidad de los problemas a resolver. Para ello se digitalizará la realidad, se
cuantizará y finalmente se abordará cada problema mediante cálculos de matemática
discreta.
A la hora de digitalizar sonido, el Teorema de Nyquist-Shannon establece el primer

límite teórico a la resolución basándose en la máxima frecuencia audible por el ser
humano promedio. Esto no sólo tiene sus consecuencias en la práctica más técnica de
tratamiento de señales, sino que abre el camino para la compresión y la psicoacústica,
conceptos estrechamente relacionados con los formatos y calidades del audio y, por
tanto, con la forma en que se capta, genera, procesa, almacena, y/o reproduce sonido.
Finalmente, la síntesis y reconocimiento del habla sirven de enlace entre la

información multimedia y la quinta generación de ordenadores que plantearon
americanos y japoneses en los años ochenta.
Por su parte, el tratamiento de imagen y vídeo, se organiza de forma análoga,

paralela, al sonido y se trabaja en el presente tema la digitalización de imagen, su
composición en color y profundidad, su tratamiento en el dominio del espacio y la
frecuencia, los formatos y códecs de imagen, así como su interrelación con el vídeo,
que podemos describir de forma tremendamente simplista, eso sí, como “imagen en
movimiento a la que podemos añadir sonido”.
Tanto en el caso del sonido como en el de la imagen, se versa también sobre algunas
de las más modernas APIs para reconocimiento del habla o visión artificial, trabajo que
generalmente se aborda con herramientas de inteligencia artificial, como las redes
neuronales tan en boga actualmente.
Joan Ferre i Ferre
1. Introducción
El uso de la palabra multimedia ha crecido de forma considerable hasta arrinconar al antaño

omnipresente imagen y sonido, término al que realmente supera, pues se dispone hoy en día de un
creciente número de medios por los que podrá transcurrir la comunicación, y multimedia no se
limitará sólo a la comunicación visual y sonora. Además, y esto también es algo cada vez más
relevante, coexistirán un humano y un dispositivo electrónico alternándose como emisor o receptor
de esa comunicación, hasta el punto de que ya hoy en día ambos pueden tanto emitir como recibir
mensajes por cualquier medio comúnmente usado, como la imagen y el sonido, cosa inimaginable
hasta hace poco. De esta forma, y por poner dos ejemplos concretos, el teléfono móvil podrá
escuchar e interpretar las órdenes humanas y una consola de videojuegos podrá ver e interpretar
los movimientos del usuario, siendo así los dispositivos tecnológicos también receptores, y no sólo
emisores, de este tipo de estímulos.
En este tema se analiza el procesamiento informatizado del contenido multimedia, básicamente

imagen y sonido, así como las principales aplicaciones y tendencias de hoy en día en este campo
del conocimiento.
2. Analógico versus digital
Escribía Zenón de Elea (490 - 430 a. C.) en su Paradoja de Aquiles y la tortuga que, tras darle a
ésta una ventaja inicial en una carrera, Aquiles nunca conseguía alcanzarla, pese a ser la tortuga
bastante lenta y él extremadamente veloz. Según Zenón, cuando Aquiles iniciaba su marcha, la
tortuga gracias a la ventaja que el guerrero le daba, ya había recorrido una cierta distancia. En el
momento en que Aquiles llegaba a la posición ocupada anteriormente por la tortuga, ésta ya había
recorrido otro tramo, situándose por delante del corredor, y así Aquiles nunca conseguiría alcanzar
a la tortuga, pese a ser mucho más rápido que ella.
Otra paradoja relatada por Zenón en sus “demostraciones de la imposibilidad del movimiento”,
según las palabras usadas por José Ferrater Mora al hablar de las paradojas de Zenón en su
definición de “absurdo” (1964, p: 39), es la conocida como Paradoja de la dicotomía. Ésta reza que
si alguien se dirige a un árbol nunca llegará a él, pues cuando haya recorrido la mitad de la
distancia, le quedará la otra mitad, de la cual primero recorrerá la mitad, quedándole la otra
mitad… y así, recorriendo tramos cada vez más pequeños, nunca llegará a su destino.
Obviamente el mundo no funciona así y hoy en día se asume que el problema con las paradojas de
Zenón es de planteamiento. Centrándonos en la Paradoja de la dicotomía, por ser la más sencilla
de analizar, se puede afirmar sin duda que hoy en día existen herramientas matemáticas para
resolverla. En época de Zenón no se conocía el Cálculo Infinitesimal y no se aceptaba, por tanto,
Tratamiento de información multimedia
que la suma de infinitos términos pudiese tener un resultado definido finito, cosa que daría solución
a la paradoja de forma obvia, pues recorrer mitades sucesivas sí llevaría a recorrer finalmente la
distancia completa. La forma de calcularlo sería con una serie geométrica como la siguiente, que
hoy en día se asume que converge a un valor finito:
Otra de las soluciones comúnmente aceptadas para las paradojas de Zenón se da haciendo uso
de la Matemática Discreta, suponiendo un universo discreto, o sea dividiendo en este caso el
espacio y el tiempo en pequeños pedazos iguales entre sí, cuantizándolos. Así, volviendo a la
Paradoja de la dicotomía, se puede afirmar que finalmente se llegará al árbol, pues al final sólo
quedará por recorrer el último intervalo de la discretización que se ha hecho de esa distancia, cosa
que se conseguirá en el último ciclo de movimiento, pues no habrá división más pequeña posible
que recorrer.
Como lo que se pretende es el tratamiento informatizado de la información, es obvio que el Cálculo

Infinitesimal no será fácilmente aplicable y que, en cambio, una solución discreta sí será
susceptible de ser informatizada con facilidad. O usando lenguaje de Teoría de la Computación,
para que un problema sea decidible necesitará consumir una cantidad finita de memoria y, por
tanto, se deberá cuantizar la realidad para hacer abordable y, por tanto, resoluble dicho problema.
Esta introducción sirve para ver que, aun partiendo de un universo y unas señales continuas, como
por ejemplo el sonido, se deberá empezar por cuantizarlas para poderles dar de forma sencilla y
efectiva un tratamiento informatizado.
Como curiosidad, cabe señalar que aún hoy en día hay debate en cuanto a la discusión “continuo”
frente a “discreto”, aunque en términos bastante más complejos y difíciles de comprender. Por
ejemplo, ha habido experimentos como los de Craig Hogan, profesor de la Universidad de Chicago
y director del Fermilab Center for Particle Astrophysics, intentando demostrar que el universo
conocido es un holograma, teoría que Hogan relaciona con la idea de que la cantidad de
información en el universo observable pueda ser finita, y el espacio-tiempo una suerte de “realidad
discreta”. De ser así, a la práctica el universo podría suponerse discreto y no continuo, al menos a
muy pequeña escala.
3. Tratamiento voz y sonido
3.1. Digitalización
El tratamiento informático de la voz y el sonido obligará, como se ha visto, a cuantizar las señales
que se capturan y, lógicamente esto deberá estar precedido de un proceso de digitalización.
Joan Ferre i Ferre
Hay que destacar que cuantizar y digitalizar no son estrictamente lo mismo. Al digitalizar
convertiremos la señal analógica a su equivalente digital, introduciendo un error que como máximo
deberá ser igual a la sensibilidad mínima del aparato digitalizador. En cambio, a la hora de
cuantizar, dependiendo de la calidad con la que se haga, o sea a la cantidad de cuantos en los que
se divida el espectro, se volverá a introducir un error al acercar el valor digitalizado de la señal al
cuanto más cercano.
Esta pérdida de calidad o distorsión será inevitable, pues de nuevo según la Teoría de la
Computación el problema deberá consumir una cantidad de memoria finita y, para ello, la
cuantización realizada deberá tener una cantidad finita de valores posibles. Puesto que la señal
analógica real previsiblemente no encajará en esos cuantos que artificialmente se han decidido, se
introducirán unos errores en la señal, que serán como máximo tan grandes como la mitad de la
cuantización, pues se ajusta el valor de la señal real a su cuanto más cercano por arriba o por
abajo.
3.1.1. Teorema de Nyquist-Shannon
El teorema de muestreo de Nyquist-Shannon, inicialmente planteado por Harry Nyquist y

finalmente demostrado por Claude E. Shannon, hace referencia a la posibilidad de reconstruir una
señal periódica continua a partir de una serie de muestras tomadas de la misma, siempre que la
frecuencia de las muestras sea al menos el doble de la frecuencia de la señal.
Como se verá posteriormente, el oído humano está limitado y, según autores, se considera que
llega a una frecuencia auditiva máxima de entre 16 y 20 kilohercios. Así, por seguridad se toma el
valor de 20.050 hercios como frecuencia máxima a digitalizar y, aplicando el teorema de Nyquist-
Shannon, se llega a los 44100 hercios usados habitualmente en las grabaciones de uso cotidiano.
Esto no quiere decir que la reconstrucción de la señal vaya a ser perfecta o que no vaya a haber
ruidos o distorsiones, ya que el teorema habla en todo momento de muestreo de la señal y no, aún,
de cuantización.
Como se ha comentado antes, cuando se produce el muestreo aún no se ha producido

cuantización. O dicho de forma más comprensible, el valor de volumen de la señal que tomamos
en el tiempo T puede tener infinitos decimales, el valor que tomamos en el tiempo T+1 también...
pero esto posteriormente se cuantizará tomando valores finitos dentro del rango de volúmenes
permitido, cambiando así el valor original y, por tanto, introduciendo una distorsión que impedirá
reconstruir fielmente la señal inicial.
3.2. El dominio del tiempo y de la frecuencia
El enfoque dado hasta ahora al tratamiento informatizado al sonido ha sido el del dominio del
tiempo. Esta forma de tratar el sonido es la más obvia, pues consideramos una señal de sonido
como un valor de volumen en cada valor de tiempo, de la forma que lo veríamos en un indicador
unidimensional de volumen, llamados comúnmente vúmetros.
Figura 1: Ejemplo de vúmetro
La otra representación habitual del sonido en el dominio del tiempo es aquella que muestra su
volumen en cada cuanto de tiempo, pero manteniendo en la representación gráfica los valores
anteriores, de forma que gráficamente se va construyendo la onda del sonido. Esta es la llamada
representación de la forma de onda (waveform en inglés):
Figura 2: Representación de forma de onda
Trabajar en el dominio de la frecuencia será distinto, pues la representación gráfica no relacionará

amplitud (volumen) en un eje y tiempo en otro, sino que relacionará amplitud y frecuencia.
Conceptualmente también es sencillo de comprender, aunque gráficamente es algo más complejo
para ejemplos reales.
Un ejemplo sencillamente visible sería el siguiente, en el que vemos cómo representar una señal
seno periódica simple. A la izquierda se muestra en el dominio del tiempo, pues los ejes horizontal
y vertical son tiempo y amplitud respectivamente, y a la derecha en el dominio de la frecuencia,
pues los ejes horizontal y vertical son frecuencia y amplitud respectivamente:
Figura 3: Representación en el dominio del tiempo (izquierda) y de la frecuencia (derecha)
Además, se sabe por análisis de Fourier que toda señal será simple o compuesta y que las señales
compuestas estarán formadas a su vez por una combinación de ondas simples con distintas
Joan Ferre i Ferre
amplitudes, frecuencias y fases. Por tanto, cualquier señal real podrá ser descompuesta, tratada, y
también representada gráficamente, mediante su gráfico amplitud-frecuencia.
La lógica detrás del MP3 y otros formatos radicará en descomponer la señal acústica compleja en
las señales simples que la componen, obviando aquellas señales de menor amplitud o las
frecuencias fuera del rango audible por el ser humano para conseguir comprimir los archivos,
reduciendo la cantidad de información que se guarda. Esto, para sonido de origen “real” como la
voz o la mayoría de los instrumentos musicales tendrá buenos resultados, pues efectivamente los
sonidos reales estarán formados por composición de ondas más simples, pues son vibraciones de
elementos sonoros como las cuerdas vocales, cuerdas de guitarras, percusión de objetos, etc. En
cambio, para señales más complejas, cuya descomposición en señales simples no sea sencilla,
como ruidos y otras señales de gran componente aleatoria, los formatos basados en transformadas
como MP3 y similares, introducirán distorsiones al no poder modelizar fielmente la señal de
entrada mediante composición de señales más simples. Este proceso de conversión de la señal
del dominio del tiempo al de la frecuencia se consigue mediante el uso de transformadas como la
de Fourier o la MDCT (Transformada de Coseno Discreto Modificada), que es la usada
actualmente en la mayoría de los formatos de compresión de audio, como el MP3, AAC o el
OGG/Vorbis.
3.3. Estándares y formatos
Una vez comprendido lo relativo a la digitalización de la información sonora, es interesante

observar cómo se almacenarán estos datos para su tratamiento. Llegado este punto es necesario
conocer la diferencia entre los formatos de fichero, generalmente conocidos simplemente como
formatos, y los códecs, o sea los sistemas de codificación y compresión de la información sonora.
Para ejemplificar metodología, y en concreto operación sobre señales de audio, se trabajará con
formato WAV y codificación LPCM (Modulación Linear por Impulsos Codificados, Linear Pulse
Code Modulation por sus siglas en inglés), por tratarse de un formato sin compresión, de estructura
sencilla y soportado prácticamente por todo tipo de software y reproductores de sonido.
El formato de un fichero de sonido determinará en qué forma se organiza la información dentro de

él. En el caso del formato WAV, la cabecera almacena información relativa al tipo de fichero,
longitud, codificación, tamaño de muestra, número de canales, frecuencia de muestreo, etc.
Después, el espacio de datos contendrá las muestras de sonido, almacenadas según la
codificación del fichero, su tamaño de muestra y su número de canales.
El formato de archivo tradicionalmente más habitual era el WAV (Waveform audio file format),
variante de RIFF (Resource Interchange File Format) desarrollado por Microsoft e IBM. De hecho,
en el inicio de un archivo WAV, en su cabecera, el primer dato que encontraremos es la cadena de
texto “RIFF” codificada en ASCII. Posteriormente vendrá indicado el tamaño del fichero (la cantidad
total de muestras que contiene), el formato (cadena “fmt” seguida de los códigos que indiquen el
tipo de codificación), el número de canales, la frecuencia de muestreo, la tasa de bits, información
de alineación de bloque y el tamaño de muestra. Posteriormente vendrá la sección de datos, que
también viene precedida por una pequeña cabecera, con las muestras de sonido una tras otra.
Este formato justamente es el mismo en el que se codifican los CD-Audio y es por ello que la
grabación de archivos WAV a formato CD (y viceversa) siempre ha sido inmediata.
Cabe destacar del formato WAV que, puesto que el tamaño del fichero se indica en la cabecera, y
que este campo que indica el número de muestras del fichero tiene una longitud fija de 32 bits, el
tamaño máximo de un archivo WAV será por tanto de 4 gigabytes. A la tasa de 1411,2 kbps de un
fichero WAV en calidad CD este fichero máximo será capaz de albergar poco más de seis horas y
media de sonido. En puntos posteriores se hablará de la tasa de bits y se explicará cómo se ha
calculado la tasa de 1411,2 kilobits por segundo para un archivo WAV estéreo de tamaño de
muestra de 16 bits.
En la actualidad, no obstante, los formatos preponderantes son otros. Ha habido un cambio de

prioridades, desde la menor exigencia de capacidad de proceso necesaria para tratar archivos
WAV que interesaba antaño, hasta el menor tamaño de archivo deseado hoy en día, así como un
avance técnico que permite una gran calidad de sonido en los códecs con compresión de sonido.
Todo esto ha hecho que formatos y códecs como OGG-Vorbis, MP3 o AAC pasen a ser los más
habituales.
Tabla I: Formatos de audio
Formato
Códecs Características
contenedor
Es el códec más usado en formato OGG.
Puede ser usado en un amplio rango de frecuencias de muestreo y
para muy diversos fines (desde baja calidad como telefonía, a alta
calidad en sonido profesional).
Usa técnicas de psicoacústica para conseguir compresión
eliminando señales menos audibles por el oído humano, al igual que
OGG Vorbis el MP3. De hecho, OGG surge como alternativa de códec libre
después de que el Fraunhofer Institute, desarrollador del MP3,
reclamase a diversos pequeños proyectos que pagasen una licencia
o dejasen de usar MPEG Audio Layer III.
La técnica que usa para la compresión es la MDCT (Transformada
de Coseno Discreta Modificada).
Soporta hasta 255 canales de audio.
Es un códec de compresión sin pérdida, como su nombre indica
(Free Lossless Audio Codec), que consigue una reducción de
tamaño del 50-60% respecto del WAV-PCM. Es mejor que aplicar
compresión ZIP a un archivo WAV-PCM pues en lugar de aplicar
compresión en bruto sobre los datos analiza el sonido: compendia
FLAC
los silencios, calcula diferencias entre señales, integra la señal de
diversos canales, etc.
Hasta 8 canales de audio.
También puede presentarse con su propio formato de archivo
contenedor.
Joan Ferre i Ferre
Tabla I: Formatos de audio (continuación)
Formato
Códecs Características
contenedor
Es un códec de compresión con pérdida.
Se puede usar a muy diversas tasas de bits, pero su punto fuerte es
un algoritmo de cálculo con muy baja latencia, o sea que se aplica a
tramos de sonido muy cortos, por lo que es aplicable a usos que
requieran un tiempo de respuesta muy rápido: telefonía y voz sobre
Opus
ip, streaming, videoconferencia, etc. Su latencia típica ronda los
25ms, aunque a bajas tasas de bits puede llegar a los 5ms, mientras
que OGG o MP3 se sitúan en el rango de los 100ms.
Fue desarrollado por la misma fundación (Xiph.Org) que Vorbis y el
propio OGG.
El MP3 es un formato de compresión con pérdidas basado en la
MDCT (Transformada de Coseno Discreta Modificada), aunque
MPEG-1
antes de la MDCT aplica un filtro llamado PQF (Polyphase
Audio
Quadrature Filter) que divide la señal acústica en 32 bandas a las
Layer III
cuales se les aplica la MDCT.
MPEG-2
Las distintas versiones de códecs MP3 básicamente determinan las
MP3 Audio
tasas de bits y frecuencias de muestreo disponibles. El de uso más
Layer III
habitual es el MPEG-1 Audio Layer III permite su uso a 64, 128, 192,
MPEG-2.5
256 y 320kbps, entre otras tasas de bits.
Audio
MPEG-1 Audio Layer III, el comúnmente usado, sólo soporta 2
Layer III
canales y, aunque MPEG-2 Audio Layer III hasta 5.1, no es usado
frecuentemente.
Hace uso de MDCT (Transformada de Coseno Discreta Modificada)
pura, aunque hace mejor uso de la ventana de datos a los que aplica
la MDCT y mejora también la aplicación de técnicas de
psicoacústica, eliminando señales difícilmente audibles mediante un
banco de filtros predefinido.
AAC AAC Permite hasta 48 canales de audio, más una cierta cantidad de
canales adicionales de subgraves y de datos.
Más frecuencias de muestreo que el MP3, desde 8 hasta 96KHz.
A igualdad de frecuencia de muestreo consigue mayor calidad de
sonido que MP3.
Es el usado en Youtube, iTunes, etc.
3.3.1. Canales
En general el sonido digitalizado siempre había sido mono o estéreo, esto es, podía tener uno o
dos canales. En las primeras grabaciones hechas con micrófono únicamente tenía sentido la
existencia de un canal, pues el micrófono tomaba sólo un juego de muestras. Posteriormente, para
explotar la capacidad estereofónica del oído humano se planteó la grabación con dos micrófonos y
también, por tanto, la reproducción mediante dos altavoces, situados cada uno a un lado del
oyente. Esto dio pie a la creación de los formatos de sonido estéreo.
También por herencia de este proceso siguen existiendo dos formas de almacenar sonido
estereofónico: estéreo dividido (split) o estéreo entrelazado (interleaved).
En el estéreo dividido o separado, cada canal de audio se almacenará como un fichero

independiente de un solo canal, y ambos ficheros deberán ser reproducidos al mismo tiempo para
conseguir el efecto estereofónico.
Fichero correspondiente al canal 1: Cabeceras Muestra 1 Muestra 2 Muestra 3 …
Fichero correspondiente al canal 2: Cabeceras Muestra 1 Muestra 2 Muestra 3 …
En el estéreo entrelazado, en cambio, las muestras de ambos canales formarán parte del mismo
fichero, alternándose las muestras de cada canal.
Cabeceras Muestra 1, Muestra 1, Muestra 2, Muestra 2, Muestra 3, Muestra 3, …

canal 1 canal 2 canal 1 canal 2 canal 1 canal 2
Actualmente es bien sabido que el sonido ha pasado también a ser multicanal. Un ejemplo lo
tenemos en los equipos de reproducción de Cine en Casa (Home Cinema), que hacen uso de las
posibilidades multicanal de los formatos DVD, Blu-ray y similares.
Por ejemplo, una sala de cine con sonido 2.1 hará referencia a que, tanto el formato de archivo que
almacena el sonido, como el códec que lo trata, como la disposición de altavoces de la sala
soportarán una configuración estéreo (dos canales laterales, izquierdo y derecho) y un canal
adicional para frecuencias graves (de ahí el .1).
Una configuración 5.1 por su parte hace referencia a la existencia de dos canales estéreo
principales, izquierdo y derecho, un canal central, dos canales estéreo traseros, izquierdo y
derecho, más un canal adicional de graves.
La diferencia entre una configuración 2.1 (dos canales estéreo más un canal de graves) y una
configuración de estéreo 3.0 (dos canales laterales más uno central) se explicará en el punto
referente a optimización y psicoacústica.
3.3.2. Tamaño de muestra
El tamaño de muestra será la agrupación mínima de sonido que se almacenará y tratará de forma
conjunta.
Joan Ferre i Ferre
Los tamaños de muestra en formato WAV más habitualmente usados son de 8 o de 16 bits en
ambientes de uso doméstico. En el primer caso el tamaño de muestra es de un byte y en el
segundo es de dos bytes, que en la arquitectura Intel se almacenan como Little-endian, o sea, con
el byte menos significativo primero. En el caso de tratamiento profesional de sonido los tamaños de
muestra habituales son 16, 24 o 32 bits, y su funcionamiento es análogo y fácilmente deducible.
Así sería la estructura de un archivo WAV mono con tamaño de muestra de 16 bits:
Muestra 1 Muestra 2 Muestra 3
Byte menos Byte más Byte menos Byte más Byte menos Byte más
Cabeceras …
significativo significativo significativo significativo significativo significativo
Y así la estructura de un archivo WAV estéreo con tamaño de muestra de 16 bits:
Muestra 1, canal 1 Muestra 1, canal 2 Muestra 2, canal 1
Byte menos Byte más Byte menos Byte más Byte menos Byte más
Cabeceras …
significativo significativo significativo significativo significativo significativo
Como se vio en el apartado sobre digitalización, el tamaño de muestra, también llamado en

ocasiones resolución, determinará la cantidad de posibles niveles de sonido que tendrá la señal.
8 16
Por ejemplo, con 8 bits habrá 2 valores que irán de 0 a 255, y con 16 bits habrá 2 valores.
Como curiosidad, cabe destacar que la codificación PCM en formato WAV de 8 bits usa valores
unsigned (sin signo) con lo que efectivamente los valores van de 0 a 255, pero el PCM de 16 bits
usa valores signed (con signo) y por tanto van del -32768 al +32767. Aunque a la práctica esto no
minora el rango sonoro, sí que es necesario tenerlo en cuenta en caso de querer procesar archivos
WAV-PCM.
3.3.3. Tasa de bits
Volviendo al ejemplo anterior, en calidad CD, esto es con una frecuencia de muestreo de 44,100
kilohercios y un tamaño de muestra de 16 bits en estéreo, un fichero WAV consumirá bits a una
tasa de 44100 hercios * 16 bits por muestra * 2 canales = 1411,2 kbps (kilobits por segundo).
Como es lógico, a mayor número de canales, mayor tamaño de muestra o mayor frecuencia de
muestreo, la tasa de bits consumida por ese sonido será mayor.
En el punto siguiente veremos cómo las técnicas de compresión y optimización actuales consiguen
no sólo bajar la tasa de bits para una calidad igual o similar, sino también que la tasa de bits sea
variable y no fija.
3.4. Optimización: compresión y psicoacústica
Al comprimir un archivo conseguiremos minorar la tasa de bits necesaria para su almacenamiento

manteniendo invariable la frecuencia de muestreo y alterando lo menos posible la calidad del
sonido original.
Aunque la compresión y la psicoacústica tienen mucha relación entre sí en el campo del sonido, no
toda la compresión usa técnicas de psicoacústica. Se puede aplicar compresión clásica sobre el
sonido, como algoritmos ZIP y similares, aunque no suele dar buenos resultados debido al tipo de
dato que el sonido representa. El paso siguiente es mejorar la compresión mediante técnicas de
análisis de las señales, compresión por diferencias, compendio de repeticiones, etc. como se hace
con el códec FLAC. No obstante, la verdadera potencia en cuanto a compresión se consigue
trabajando en el campo de la frecuencia, mediante transformadas, y aplicando técnicas de
psicoacústica.
Básicamente la psicoacústica aportará un enfoque que facilitará:
• Eliminar frecuencias fuera del rango audible
• Eliminar señales con una intensidad relativa baja
• Eliminación de harmónicos cercanos, sobre todo en frecuencias donde es más compleja su

percepción
• Correcciones de fase o de panorama (mono-estéreo) sobre señales de difícil percepción
Así, es posible que un archivo WAV-PCM que consuma 1411,2 kbps tenga una calidad de sonido
difícilmente distinguible, incluso para oídos entrenados, que el mismo sonido codificado como
archivo MP3 a 320kbps.
Además de todo esto, existe la posibilidad de codificar a una tasa de bits variable, optimizando la
cantidad de bits que necesite el sonido en cada momento y llegando a bajarla sustancialmente
cuando, por ejemplo, la grabación contenga silencio y se pueda representar esa información con
mucha menor cantidad de bits.
Finalmente, dejando de lado la compresión, es interesante destacar también la importancia de la

psicoacústica en relación al número de canales en que se organiza una obra sonora. Así, será muy
distinto el uso de un sistema de sonido 2.1 que un estéreo 3.0, pese a contar ambos sistemas con
tres canales de sonido.
El sonido 2.1 está pensado para colocar un tercer canal de subgraves, que da más cuerpo y
realismo al sonido. La lógica detrás de esto reside en que la música contemporánea suele colocar
centradas en el panorama estéreo las frecuencias más graves para conseguir la mayor potencia
sonora de ese grave al sonar igual por ambos canales izquierdo y derecho. Así, en lugar de
Joan Ferre i Ferre
incorporar una caja de graves importante en cada altavoz izquierdo y derecho, se puede “aislar el
factor común” y conseguir ese sonido con una sola caja central. Además, el sonido 2.1 también
evita que en algunos casos las frecuencias más graves queden canceladas y sean casi inaudibles
en algunas posiciones de una sala por llegar las señales de ambos altavoces con la fase
completamente invertida. Al ocurrir esto las señales se restan, o sea que compensan su presión
sonora, dejando así al oyente sin percibir esas frecuencias.
El sonido estéreo 3.0, en cambio, sigue una lógica completamente distinta, por venir a resolver un
problema distinto, y está más enfocado al uso en reproducción de vídeo, como por ejemplo en
cines. El problema de un cine con sonido en estéreo básico izquierda-derecha radica en dónde se
sienta el espectador. Así, un espectador sentado en el centro de la sala tendrá una percepción
perfecta al estar a igual distancia de los altavoces izquierdo y derecho, mientras que un espectador
sentado en un lateral pierde la perspectiva sonora. Los sonidos de la película centrados, que
suenan por igual en ambos canales izquierdo-derecho, al espectador sentado a la derecha de la
sala le parecerá que provienen del altavoz del lado derecho, pues es el que tiene más cerca,
dándole la extraña sensación de que el “centro” de la película suena por la “derecha”. La
colocación del altavoz central del estéreo 3.0 soluciona en parte este efecto, pues los sonidos
centrados suenan sobre todo por el altavoz central, dándole mucho mejor perspectiva al
espectador que está sentado en un lateral, sin variar la correcta perspectiva de un espectador
centrado.
La misma lógica de los sistemas 3.0 se aplica al 4.0, con izquierda-derecha frontales e izquierda-
derecha traseros, y al 5.0 que añade el canal central a la configuración anterior. En todos los
casos, además, se puede aislar el canal de subgraves obteniendo sistemas 3.1, 4.1, 5.1, etc.
Además, el uso de canales traseros, o incluso superiores hasta llegar a configuraciones como 7.1,
tiene su explicación en la mejora de la sensación envolvente del sonido, permitiendo que pueda
haber sonidos que realmente suenen detrás o arriba del espectador.
3.5. Síntesis de voz (text-to-speech o TTS)
La síntesis de voz es una disciplina con una larga historia a sus espaldas, pues en la década de
los sesenta ya se consiguió la síntesis informatizada de voz y en los setenta había incluso
productos comerciales que incluían síntesis de voz, como la calculadora Speech+ para invidentes
fabricada en 1976 en los Estados Unidos por la compañía Telesensory Systems Inc.
Las tecnologías para la síntesis de voz se suelen categorizar en relación a la técnica mediante la
cual realizan la tarea, y podemos distinguir principalmente cuatro:
• La síntesis por concatenación. Se parte de un corpus de difonemas o semisílabas

grabadas de la voz de un lector y con ellas se construye el discurso. La calidad es bastante
alta, aunque la grabación y trabajo del corpus es trabajosa y voluminosa. Algunos idiomas,
como el español, tienen menos de mil difonemas mientras que lenguas como el alemán
presentan más de dos mil. Lógicamente, cambiar de idioma suele ser costoso, pues obliga
a regenerar el corpus.
• La síntesis por formantes. Su idea es modelizar una fuente de aire o sonido, imitando
generalmente a las cuerdas vocales del aparato fonador humano, y aplicar posteriormente
filtros que, imitando a las cavidades que se generan y varían con el habla, modifican el
sonido que emite la fuente mediante la resonancia. Son bastante usados, aunque su
calidad no es excesivamente alta. Implementar un nuevo idioma no es excesivamente
gravoso.
• La síntesis articulatoria. Va un paso más allá de la síntesis por formantes y modeliza toda
la fonación humana: la vibración de las cuerdas vocales (sonidos sonoros), la espiración de
aire (sonidos sordos) y las piezas articuladas (labios, lengua, etc.) que modifican el sonido
generado. Aunque su procesamiento es costoso, ofrece un gran control sobre los
parámetros prosódicos (duración, tono y energía) y, además, el cambio de idioma es
relativamente sencillo.
• La síntesis por técnicas de predicción lineal. Se basa en técnicas matemáticas de

procesamiento de señales para intentar inferir la función de transferencia del filtro que ha
generado cada señal, para poder construir lenguaje hablado como una serie de funciones
de transferencia de filtros aplicadas una detrás de otra. Es un modelo considerablemente
artificial que tradicionalmente ha dado resultados con sonido robótico y no excesivamente
inteligibles, pues modeliza bien los sonidos sonoros, aunque no los sonidos sordos ni las
transiciones de los difonemas. Cambiar de idioma es relativamente sencillo, aunque obliga
a estudiar de nuevo el corpus del nuevo idioma.
Además, un sistema de TTS constará habitualmente de dos partes, el frontend y el backend.
El frontend se encargará de:
• Recoger la entrada de texto en formato escrito
• Realizar un análisis fonético para proponer los fonemas
• Realizar un análisis lingüístico para analizar los tipos de palabras del mensaje
• Realizar un análisis prosódico para detallar las duraciones, tonos y energía de cada
sección de sonido que se va a generar
El backend por su parte, será el encargado de:
• Recoger la entrada de fonemas y esquema de prosodia proveniente del frontend
• Sintetizar el habla mediante la técnica correspondiente, para generar una salida en formato
audible
Joan Ferre i Ferre
3.6. Reconocimiento del habla (speech-to-text o STT)
Cuando se estudia historia de la computación se revisan las características básicas que definen a
cada una de las generaciones de computadores:
• Generación 0: máquinas de cálculo mecánicas
• Generación 1 (años 50): uso de válvulas de vacío
• Generación 2 (primera mitad de los 60): uso de transistores
• Generación 3 (segunda mitad de los 60): uso de circuitos integrados
• Generación 4 (años 70): toda la CPU en un único circuito integrado
• Generación 5 (años 80 en adelante): ya se observa la importancia de “hablar” con el

ordenador, pensando en el lenguaje natural humano y no en el código máquina, la
inteligencia artificial, la robótica, las redes de comunicación, etc.
Es interesante ver cómo las primeras generaciones se centran en mejorar los ordenadores en
cuanto a tecnología y arquitectura físicas. No obstante, en la quinta generación, Japón y Estados
Unidos empiezan a desarrollar programas específicos en la línea de mejorar la capacidad de
proceso de los ordenadores mediante software, pensando en que sea el computador quien se
acerque al lenguaje natural y no el usuario quien se acerque al lenguaje máquina. Así florecen
ciertas ramas de la computación como la inteligencia artificial. Todo ello dará pie a usos avanzados
como el reconocimiento del habla o el reconocimiento de imagen que se trata posteriormente en
este mismo tema.
Simplificando, se puede dividir el uso de la inteligencia artificial en dos, según su método de

razonamiento: deductivo e inductivo. Así, un método deductivo parte de unas leyes o principios
generales, que aplica para razonar un resultado. Este es el caso de los llamados Sistemas
Expertos o de los ATP (Automated Theorem Proving en inglés o Demostración Automática de
Teoremas en español) para deducción automatizada. Un método inductivo, por su parte, trata de
conseguir los conocimientos a partir de entradas o estímulos reales del trabajo que debe realizar,
como los métodos de reconocimiento de patrones kNN (k vecinos más cercanos) o las redes
neuronales.
En el caso del reconocimiento del habla, no será sencillo conseguir un sistema plenamente
deductivo, pues sería muy complejo establecer unas reglas universales de partida para interpretar
a cualquier tipo de hablante en cualquier situación, debido a la gran variabilidad de fuentes
(idiomas/dialectos, acento, dicción, tono, entonación, etc.) y situaciones (ruido,
reverberaciones/ecos, etc.). Así que los sistemas de reconocimiento del habla serán, o bien
puramente inductivos, o bien una conjunción de reglas iniciales, para el razonamiento deductivo,
alimentadas de muestras reales para el procesado inductivo.
Además, desde que grandes empresas como Google (Alphabet Inc.) o IBM (International Business
Machines Corporation) están ofreciendo el uso mediante API de estas herramientas, su potencial
está ya llegando al gran público mediante su conexión con aplicaciones de uso cotidiano. Por
ejemplo, se puede consultar en internet un proyecto llamado Speech to Text dentro del ecosistema
Watson Developer Cloud de IBM.
El proyecto Speech to Text de IBM ofrece una propuesta de transcripción del texto que ha oído y,
además, una serie de alternativas de palabras en todas aquellas que puedan requerir de
desambiguación. Por tanto vemos que el sistema no es perfecto, pues el reconocimiento del habla
requiere no sólo de la captación y conversión del sonido en texto, sino que también requiere del
análisis de la temática y el contexto de la oración. Estos sistemas dan, ya en la actualidad, muy
buenos resultados cuando los resultados son susceptibles de desambiguación de forma sencilla,
bien sea porqué la cantidad de palabras a reconocer es relativamente baja o porqué el contexto, y
por tanto el léxico, está bastante acotado. Esto marca el tipo de situaciones en que son usados
actualmente este tipo de sistemas: que el usuario diga números, que el usuario diga la causa de un
fallo de entre una serie de causas posibles, que el usuario diga su teléfono o dirección, etc.
Como otros ejemplos de cada vez mayor difusión se podrían citar los asistentes por voz, cuyo uso
están potenciando las grandes marcas, como Siri (de Apple Computer Inc.), OK Google (de
Alphabet Inc.) o Cortana (de Microsoft Corporation). La finalidad de estas herramientas es, como
se planteó con la quinta generación de computadores, acercar el computador al humano haciendo
que el computador sea quien aprenda el lenguaje humano y no al contrario.
4. Tratamiento de imagen
4.1. Digitalización
Al igual que ocurre con el sonido, el tratamiento informatizado de imagen digital obligará a
digitalizar las señales de origen. Esto, además de ser la forma de trabajo habitual para la
informatización de datos, es la forma de cumplir con la Teoría de la Computación para hacer
abordable, o sea decidible, el problema y, de esta forma, intentar resolverlo.
La digitalización en imagen, bien sea mediante un escáner, una cámara fotográfica o cualquiera
otro tipo de dispositivo de captación, se basa en dividir la realidad en puntos, pequeños elementos
de imagen independientes llamados píxeles, y de los cuales se almacena su información de color,
intensidad, luminosidad e, incluso, de otros datos o matices relativos a la imagen original.
En una simplificación extrema, si un sistema capta una letra F y se digitaliza en monocromo, se

obtendría una matriz de puntos, píxeles, cuyo valor sería únicamente blanco o negro.
Joan Ferre i Ferre
Figura 4: Digitalización en monocromo de la imagen de una letra F
Lógicamente esta digitalización, igual que se explicaba con el sonido, introducirá distorsiones
respecto del contenido original ya que, al digitalizar, se perderá detalle, y por tanto calidad, de la
imagen original. La imagen anterior, en una digitalización con mayor número de píxeles, podría
haber quedado así:
Figura 5: Digitalización en monocromo de la imagen de una letra F (2)
De esta forma observamos cómo, la digitalización introduce errores, al no ser capaz de representar
fielmente la imagen original, en este caso los detalles a la derecha de cada una de las líneas
horizontales de la letra F, arriba y debajo.
Además, en el caso de imagen animada o vídeo, el funcionamiento será el mismo, aunque se

obtendrá una captación de imagen cada cierto tiempo, dando lugar a una cierta cantidad de
imágenes por segundo, que determinará la frecuencia de refresco de nuestro vídeo.
4.2. Color
Principalmente existen tres formas de representar el color en informática.
• HSB (Hue, Saturation, Brightness), esto es matiz/tono, saturación y brillo/luminosidad.
El tono está directamente relacionado con la longitud de onda de la luz que se

representa. Desde la de menor energía (colores rojizos), pasando por amarillos y
verdes, hasta la de mayor energía (colores azules/violáceos).
La saturación está relacionada con la viveza del color, un color más saturado es más
vivo y uno menos saturado es más apagado.
Joan Ferre i Ferre
La luminosidad está relacionada con la cantidad de luz que el color refleja. A mayor
luminosidad se da un color más tendente al blanco y a menor luminosidad, un color
tendente al negro.
• RGB (Red, Green, Blue), esto es, rojo, verde y azul.
Es la forma en que funcionan las pantallas actuales, por composición de los tres
distintos tonos de luz, llamados colores primarios.
Esta forma de conseguir cualquier color mediante la suma de colores primarios en

distinta intensidad se llama ‘síntesis aditiva’.
Cabe destacar que RGB es una composición teórica y que ni la vista humana es capaz
de ver todos los colores ni, por supuesto, los monitores son capaces de representarlos
todos. Así, se crearon algunos modos de color que son subconjuntos del RGB
absoluto, como son sRGB (standard RGB IEC61966-2.1) o el AdobeRGB (Adobe RGB
1998), que básicamente restringen los posibles colores que se permiten.
• CMYK (Cyan, Magenta, Yellow, Black), esto es cian, magenta, amarillo y negro.
Su lógica de funcionamiento es la contraria al modelo RGB. En lugar de sumar colores

(luz), lo que se hace es añadir una tinta que absorberá ciertas longitudes de onda y
reflejará el resto. Si se van añadiendo tintas que absorben diferentes longitudes de
onda, cada vez menos longitudes de onda son reflejadas, y al final ninguna luz es
reflejada. Este tipo de síntesis de color se llama ‘síntesis sustractiva’.
Es el modo de color usado en impresión, ya que necesariamente se debe de partir de

tintas que absorban longitudes de onda, en lugar de partir de emisores de luz como
hacen las pantallas.
Teóricamente las tintas cian, magenta y amarilla (CMY) sumadas ya deberían dar
como resultado una imagen en tono negro, aunque no siempre es así. Para conseguir
tonos negros más realistas, y para evitar saturar el papel con la suma de tres tintas, se
añade también la tinta negra. Esto da como resultado el uso de cuatro tintas, en lugar
de tres. Por esta razón, en el gremio de la impresión, se suele llamar a este modelo
cuatricromía.
• ICC (International Color Consortium)
Creado en el 1993 por diversos fabricantes de las industrias electrónicas, del software
y el diseño o las artes gráficas.
Definen unos perfiles, llamados perfiles ICC, para cada dispositivo que debe tratar,
representar, visionar, imprimir… color. De esta forma, y mediante los llamados PCS
(Profile Connection Space) planteaban, teóricamente, conseguir la representación
fidedigna de color entre distintos dispositivos y, como consecuencia, la convertibilidad
entre distintas representaciones de color como RGB, CMYK…
Además de disponer de distintos modelos de representación del color, se ha de tener en cuenta el

concepto de ‘profundidad del color’, que hace referencia a la cantidad de bits de que se dispone
para representar dicho color. Si la profundidad de color se limitase a un bit, se dispondría
únicamente de dos estados, dando como resultado imágenes monocromas estrictas, como la letra
F representada anteriormente, independientemente del modo de color (HSB, RGB, CMYK) usado
para representar la imagen.
Así, a mayor profundidad de color, más cantidad de tonos distintos se podrán representar, más fiel
será la representación que se haga de la imagen original y, finalmente, mayor calidad se percibirá.
4.3. El dominio de la frecuencia y el del espacio
De forma análoga a cómo se hace con el sonido, que se puede procesar en el dominio del tiempo y
la frecuencia, la imagen puede ser procesada en el dominio del espacio y, también, de la
frecuencia. El procesamiento en el dominio del espacio se parece bastante a lo visto anteriormente
en este mismo tema, tratando la imagen como una matriz de puntos individuales, independientes, a
los que podemos aplicar operaciones. Este tipo de operación se llama ‘operación punto a punto’ o
‘procesamiento de punto’. Por el contrario, si se considera la imagen como una representación, una
captación, de una realidad continua resulta interesante considerar métodos de tratamiento de
señales que ayuden a modelizar la realidad mediante herramientas matemáticas. En el caso de la
imagen se hace generalmente uso de la Transformada de Fourier en su versión Discreta (DFT), y a
los datos resultantes, generalmente se les aplican ciertos filtros para eliminar las distorsiones que
la propia DFT pueda crear, al introducir en la imagen procesada harmónicos que no existían en la
imagen original.
4.3.1. Operaciones punto a punto
El procesamiento de imagen punto a punto consiste, como se ha descrito anteriormente,

únicamente en aplicar la misma operación a cada píxel de la imagen.
La mayoría de efectos clásicos de retoque de imagen por su sencillez son, por tanto, operaciones
punto a punto, como la corrección de color, saturación, brillo, inversión de color,
reducción/ampliación de rango dinámico, etc. así como la mayoría de operaciones de composición
de imagen en capas.
4.3.2. Filtrado y transformadas
El procesado digital de imagen descansa sobre esta filosofía básica para intentar adaptar la
imagen al uso que se le desea dar. El filtrado se basa en la idea de conseguir eliminar aquellos
detalles de la imagen que empeoran el tratamiento que se le puede dar o, de forma análoga,
potenciar aquellos detalles considerados importantes o característicos de dicha imagen. Este
proceso se concretará, por una parte, en suavizar imágenes, proceso más que adecuado sobre
todo por la dureza que impone la digitalización al pixelar la imagen, por otra parte, en eliminar las
llamadas distorsiones o ruidos, pues la digitalización y otros procesos también pueden incorporar a
Joan Ferre i Ferre
la imagen artefactos extraños que no presentaba el original y, finalmente, también detectar y

potenciar los bordes naturalmente presentes en la imagen, como representación que es de una
realidad, para conseguir una imagen más nítida y en la que se puedan identificar más fácilmente
todos sus elementos.
Si para simplificar se toma una imagen muy sencilla, como podría ser una imagen de una única fila
de píxeles, con esta disposición:
Figura 6: Imagen de ejemplo con una sola fila de píxeles
En esta imagen, el color pasa gradualmente de un tono gris medio a blanco, para después
gradualmente, pasando de nuevo por el gris, ir al negro y volver finalmente al gris de inicio.
Si se intentase representar esta transición de tonos mediante un gráfico en el que el eje horizontal
fuese la posición en la imagen y el eje vertical el tono de gris, se obtendría un gráfico similar al
siguiente, en el que la mayor amplitud positiva de la onda representaría el blanco y la menor
amplitud el negro, siendo el punto intermedio el gris:
Figura 7: Representación, en el dominio de la frecuencia, de la imagen anterior
Llegados a este punto es sencillo, sobre todo una vez visto este proceso en el sonido, establecer la
correspondencia de esta representación con una señal seno y comprender que se podrá
almacenar la información de la imagen inicial como una señal simple de frecuencia F, amplitud A y
con un offset o desplazamiento inicial tal que convierta su máximo en el blanco de la imagen y su
mínimo en el negro. También como se vio con el sonido cabe recordar que, según Fourier, toda
señal compleja podrá ser descompuesta por una suma de señales simples de distinta frecuencia,
amplitud y fase.
Con esta filosofía y base matemática se trata la imagen para conseguir representarla como una
composición de ondas simples mediante la aplicación de la Transformada Discreta de Fourier (DFT
en sus siglas en inglés) bidimensional.
Además, de forma también análoga a diversos códecs de compresión de audio, generalmente se

aplican filtros al resultado de la DFT para conseguir ciertos objetivos. Por ejemplo, un filtro paso
bajo eliminaría las frecuencias altas, que representarán los cambios bruscos de intensidad en una
imagen, ayudando así a suavizarla, por ejemplo, con la intención de eliminar ruidos o distorsiones,
o de disimular el pixelado presente en una imagen digital. Un filtro paso alto conseguiría el efecto
contrario, remarcar los cambios de intensidad bruscos en una imagen, algo que podría servir para
intentar remarcar los bordes de los elementos naturalmente presentes en una imagen y aumentar
su nitidez. Estos filtros comentados, que trabajan en el dominio de la frecuencia, no son los únicos
filtros posibles. También es posible implementar filtros en el dominio del espacio, cuya operación
se realiza directamente sobre los píxeles. Un ejemplo sencillo de comprender es un filtro promedio
que coloque en cada píxel el valor promedio de sus vecinos iniciales. De esta forma se conseguiría
difuminar la imagen, dando lugar a un efecto similar a la niebla o a ver a través de un cristal
empañado.
4.4. Formatos
En el caso de la imagen, al igual que ocurre con el sonido, se dispone de diversos formatos de
archivo que además recogen distintas formas de compresión. Los más habitualmente usados son
los siguientes:
Tabla II: Formatos de imagen
Formato Características
Es un estándar de facto que soporta gestión de color RGB, CMYK, YCBCR o
mediante su propia paleta de colores, entre otras configuraciones. Tiene una
profundidad de bits bitonal de 1 bit, en escala de grises de 4 u 8 y hasta 64 bits
TIFF
en color, aunque a la práctica la mayor parte de aplicaciones sólo llegan a los 24
bits en color. Soporta compresión con pérdidas JPEG y también compresión sin
pérdidas ITU-T.6, LZW y otras.
Se trata también de un estándar de facto, que permite gestión de color mediante
su propia paleta con una selección de hasta 256 colores. Tiene una profundidad
de bits bitonal, en escala de grises o color de entre 1 y 8 bits, dando lugar con
GIF 8
los ocho bits máximos a esos 2 = 256 colores máximos posibles. Únicamente
permite la compresión LZW y se trata, por tanto, de un formato con compresión
sin pérdidas.
Es un estándar ISO (10918-1/2) que permite únicamente la gestión de color
YCBCR. Su profundidad de color en escala de grises es de 8 bits y, en color, de
JPEG
24 bits. Existe especificación JPEG sin pérdidas, aunque no suele ser soportada
y la única configuración posible es propia la compresión con pérdidas JPEG.
Es un estándar ISO (15948) nacido con la intención de reemplazar a GIF en el
uso en web. Los modos de gestión de color que permite son sRGB, su propia
paleta de color o ICC. Su profundidad de bits va de 1 a 48 bits en varios modos.
PNG
Un primer modo de 8 bits en color, escala de grises de 16 bits y finalmente en
color hasta 48 bits. Trabaja con compresión sin pérdida Deflate, surgida de
LZ77.
Joan Ferre i Ferre
Tabla II: Formatos de imagen (continuación)
Formato Características
WebP Está llamado a ser un estándar, nacido a partir del formato de vídeo VP8 y que
se extiende debido a la apertura del mismo, con licencia BSD, por parte de
Google después de la adquisición de la compañía On2 Technologies, su
desarrolladora original. El modo de color recomendado por Google es ICC y se
asume sRGB en caso contrario. Su profundidad de color es de sólo 8 bits, pues
es un formato pensado para la web y tiene como uno de sus objetivos básicos el
generar archivos de bajo peso. Puede funcionar en compresión con y sin
pérdida, con métodos desarrollados por el equipo de VP8 y el de WebP
respectivamente. Google además ha publicado VP9, trabaja en VP10 y AV1 y,
entre otras cosas, se ha hablado de dotar a WebP, en su siguiente versión, de
mayor profundidad de color, aunque evolucionar WebP no parece ser una
prioridad para la compañía.
Se cita este formato simplemente como ejemplo de lo abierto que actualmente
está el desarrollo de formatos de compresión de imagen y vídeo. FLIF es un
FLIF formato de compresión sin pérdidas, abierto con licencia LGPL3, que afirma
conseguir mejor compresión que sus equivalentes (sin pérdidas) WebP, PNG,
JPEG, etc.
Es un formato estándar desarrollado por el W3C, vectorial, y por tanto escalable,
y de ahí viene su nombre en inglés, Scalar Vector Graphics. Está basado en el
lenguaje de marcas XML y establece una metodología de almacenamiento de
SVG
imagen en dos dimensiones con soporte limitado para la animación e incluso la
interacción con el usuario. El color se establece en RGB de la misma forma que
en CSS, por ejemplo #2A224F o bien rgb(212, 22, 63).
El formato RAW, o datos en crudo, es un almacenamiento de imagen casi sin
procesar salidas de equipamiento de toma de imágenes como cámaras de
fotografía. También se les llama, por tanto, negativos digitales. Al salir
RAW directamente de los sensores de la cámara, no se puede establecer un perfil de
color compartido para todo archivo RAW, ni tampoco de profundidad de color,
sino que más bien dependerá de cada máquina que tome las imágenes.
Por supuesto que estos formatos no son los únicos, como se ha comentado, los hay muchos y muy
variados y hoy en día hay gran trabajo de desarrollo, centrado entre otras cosas en el trabajo de la
comunidad, con el desarrollo de formatos abiertos y de las propias compañías, en una suerte de
batalla legal-empresarial por intentar imponer sus propios formatos y no depender de los formatos
de la competencia, en un juego donde entran en danza las posibles regalías que debería pagar
una empresa que usase estándares cerrados de otra compañía. Es por ello que compañías como
Google o Apple se han interesado en los últimos años por los formatos de sonido, imagen y vídeo.
4.5. Vídeo
El vídeo, como imagen en movimiento, puede ser tratado de muy distintas formas. En sus inicios
se planteó de la forma más obvia, como una serie de imágenes almacenadas y proyectadas de
forma consecutiva. La digitalización del vídeo, por tanto, se planteaba como la digitalización de
imágenes independientes y de esa forma surgieron los primeros formatos de vídeo digital.
El problema surgía, lógicamente, al tener que almacenar la ingente cantidad de información que
suponen todos los fotogramas de un vídeo en calidad suficiente y sin compresión alguna.
En este punto cabe recordar que el vídeo hoy en día está disponible habitualmente en tasas de 25
ó 29,97 FPS (Frames Per Second o Fotogramas Por Segundo), aunque los monitores llegan a
tasas de refresco de imagen mayores (típicamente 50 ó 60 Hercios y actualmente los 90 ó 100 Hz
ya son valores habituales en monitores o en cascos de realidad virtual como Oculus Rift o HTC
Vive).
Además, los formatos o ratios de aspecto más habituales en tratamiento de vídeo son los
siguientes:
• 352x240: NTSC de baja calidad
• 352x288: PAL de baja calidad
• 640x360: Vídeo de Baja Definición (SD)
• 640x480: VGA
• 720x480: NTSC
• 720x576: PAL
• 800x600: SVGA
• 1024x768: XGA
• 1280x720: Vídeo de Alta Definición 720p (HD 720p)
• 1280x1024: SXGA
• 1920x1080: Vídeo de Alta Definición Completa 1080p (FHD 1080p)
• 2560x1440: Vídeo de Ultra Alta Definición 2K (UHD 2K)
• 4096x2160: Vídeo de Ultra Alta Definición 4K (UHD 4K)
Joan Ferre i Ferre
Dado que el almacenamiento de tanta información de vídeo era un problema y que ya existían
métodos de compresión para imágenes, el siguiente paso era evidente.
Al igual que en sonido, en vídeo se dispondrá de un formato contenedor de archivo, por ejemplo
AVI, MKV, OGG, MOV o WebM, y de diversos códecs para la compresión del vídeo, como DIVX,
XVID, x264, Theora, VP9. Además, se hará uso también de los códecs de compresión de audio
para la compresión del sonido del vídeo, si es que éste lo tiene. Si un vídeo no usa códec se estará
almacenando en formato RAW (en crudo, sin ningún tipo de compresión), lo que puede llegar a
generar archivos de un tamaño muy importante.
4.5.1. Compresión intra-frame e inter-frame
Precisamente para evitar obtener archivos de vídeo de gran tamaño, se aplican distintos tipos de
compresión mediante códecs. Por un lado, la compresión intra-frame se basa en tratar, y
comprimir, un frame como imagen aislada mientras que, por otro, la compresión inter-frame, trata
de lograr compresión relacionando cada fotograma con sus fotogramas anteriores y/o posteriores.
Tal como se explicó en la compresión de vídeo, los mecanismos de compresión mediante
transformadas se basarán en descomponer la señal compleja que genera la realidad en las
señales simples que la componen, para así almacenar únicamente los datos relativos a esas
señales en el dominio de la frecuencia. Esto se podrá conseguir tanto en las dimensiones de un
fotograma estático (imagen de la izquierda) como entrelazando los fotogramas consecutivos de un
vídeo.
Figura 8: Representación del análisis para compresión en imagen (izquierda, un solo fotograma) y
en vídeo (derecha, más de un fotograma)
Puesto que ya se dispone de herramientas, como JPEG, para conseguirlo con una imagen, la
implementación para vídeo es inmediata.
Así, los códecs más simples únicamente realizan compresión intra-frame y los más complejos
trabajan la compresión inter-frame, no sólo para calcular los frames siguientes, sino también los
anteriores.
Existen tres tipos de frames: I-frames, P-frames y B-frames. Los I-frames (Intra-Coded Images) son
las imágenes auto-contenidas, como una imagen JPEG normal. Los P-frames (Predicted Image)
son imágenes cuya información se calcula a partir del frame anterior. Los B-frames (Bi-predicted
Image) son imágenes cuya información se calcula a partir del frame anterior y el siguiente. Como
ya se vio, la realidad no causa imágenes con información de alta frecuencia en el dominio de la
frecuencia, pues serían muy abstractas, y esto ayuda a comprimir mediante transformadas. De
igual forma, un fotograma y su fotograma siguiente serán semejantes (sino iguales) pues la
realidad no puede causar, salvo en contadas ocasiones, un constante cambio brusco de imagen de
un fotograma al siguiente. Esto también ayudará a conseguir un notable ahorro de información
mediante compresión inter-frame.
Los formatos contenedores más habituales, y sus códecs son los siguientes:
• MPEG-1: usa VCD para vídeo y MP1, MP2 o MP3 para audio. Llamado habitualmente
“calidad CD”.
• MPEG-2: usa SVCD para vídeo y MP3 o AAC para audio. Llamado habitualmente “calidad
DVD”.
• MP4: usa sobretodo algún códec que cumpla la especificación H.264 (como por ejemplo el
códec libre x264) y AAC para audio.
• AVI: desarrollado por Microsoft, es uno de los históricamente más extendidos. Acepta gran
cantidad de códecs (DV, Cinepak, Intel Video 5, etc.), aunque los más usados son DivX y
XviD debido a su buen nivel de compresión en el momento de su popularización. Cuando
DivX se cerró (no se permitió su uso libre), XviD surgió como alternativa libre, de
tecnología muy similar y mejor rendimiento y ocupó su lugar.
• RM: formato Real Media, de Real Networks usa códecs propios tanto para vídeo como
para audio.
• MKV: el formato Matroska es totalmente abierto, usa generalmente el códec x264 y como
códec de audio suele usar Vorbis, por ser también abierto.
• OGG: formato libre que usa Theora para vídeo y Vorbis u Opus para audio. Como en cierta
época se extendió su uso para audio sin vídeo (como alternativa libre al MP3), se tiende a
llamar OGG al archivo que únicamente contiene audio y OGM al OGG con vídeo Theora.
• MOV: formato desarrollado por Apple. Actualmente es equivalente a MP4, usando una
implementación de h.264 cerrada y audio AAC.
• 3GP: usa implementaciones de h.263 y h.264 para el vídeo y generalmente ha sido usado
en dispositivos móviles buscando una gran compresión y tamaños de fichero muy
reducidos.
• WebM: inicialmente desarrollado por On2 Technologies y liberado por Google. Usaba el
códec VP8 para vídeo y Vorbis para audio, y actualmente usa VP9 para vídeo y Opus para
audio.
4.6. Reconocimiento de imagen
El reconocimiento informatizado de imagen tiene como objetivo la obtención, a partir de la imagen

digital, de datos que sean fácilmente interpretables y procesables, de la misma forma en que
funciona el cerebro humano, procesando la información percibida. También de la misma forma que
el cerebro humano, es habitual que se implemente el reconocimiento de imagen mediante sistemas
de redes neuronales. Es el caso de la API Cloud Vision, de Google (Alphabet Inc.), interfaz de
Joan Ferre i Ferre
programación de aplicaciones de libre uso para reconocimiento de imagen, que se puede encontrar
aquí: https://cloud.google.com/vision/
Las redes neuronales aprenderán, como también hace el ser humano, a partir del ejemplo y así la
capacidad de empresas como Google para disponer de una base de datos, en constante
crecimiento, con millones de imágenes será una pieza fundamental para evolucionar sus sistemas
de inteligencia artificial, entre otros usos, para entrenarlos con la mente puesta en el
reconocimiento de imagen. En este sentido una vez que Google dispone de los datos para entrenar
sus redes neuronales, abrir una API para que el gran público desarrollador trabaje y desarrolle sus
aplicaciones les facilitará el siguiente paso de la evolución del sistema: la decisión, la capacidad de
tratar los datos que extraiga la red neuronal para interpretar la realidad de forma efectiva, mediante
la informática.
(1) Ferrater Mora, José (1965). Diccionario de filosofía, quinta edición. Ed. Sudamericana Buenos
Aires.
(2) Soliman, S. & Srinath (1999). Señales y sistemas continuos y discretos. Ed. Prentice Hall.
(3) Información del Center for Computer Research in Music and Acoustics, de la Universidad de
Stanford (EE.UU.) https://ccrma.stanford.edu
(4) Material del profesor Joaquim Llisterri del Grup de Fonètica del Departament de Filologia
Espanyola de la Facultat de Filosofia i Lletres de la Universitat Autònoma de Barcelona:
http://liceu.uab.es/~joaquim
(5) Material del profesor Agustín Gravano del Departamento de Computación de la Universidad de
Buenos Aires (Argentina), perteneciente al grupo de Procesamiento del Habla y del
Laboratorio de Inteligencia Artificial Aplicada: http://habla.dc.uba.ar/gravano
(6) Documentación sobre WebM (VP8/VP9) y WebP de Google: https://www.webmproject.org/

https://developers.google.com/speed/webp/docs/riff_container
(7) Otros formatos de imagen, FLIF http://flif.info/
(8) Material del Instituto de Formación y Recursos en Red para el Profesorado del Ministerio de
Educación, Política Social y Deporte sobre Diseño de Materiales Multimedia:
http://www.ite.educacion.es/formacion/materiales/107/cd/video/video0102.html
(9) Enciclopedia libre Wikipedia https://www.wikipedia.org
Tema 24. Arquitecturas de sistemas de
información. El procesamiento cooperativo y la
arquitectura cliente-servidor
Javier Botana Gómez

Colegiado 0716
Una gran parte de las ocupaciones profesionales está vinculada en la actualidad a la

creación, procesamiento y distribución de información. Nos enfrentamos a un cambio
social sin precedentes, provocado por un rápido aumento de la eficiencia de la
microelectrónica, la reducción de costes en el tratamiento de la información y por la
convergencia de áreas como las telecomunicaciones y la informática.
Los sistemas de información son un conjunto de elementos orientados al tratamiento y

administración de datos e información, organizados y listos para su uso posterior,
generados para cubrir una necesidad o un objetivo.
El procesamiento cooperativo es el que utiliza plataformas software y hardware de

diferentes suministradores como soporte para la ejecución de una aplicación global.
La arquitectura Cliente-Servidor es un modelo para el desarrollo de sistemas de

información en el que las transacciones se dividen en procesos independientes que
cooperan entre sí para intercambiar información, servicios o recursos. Se denomina
cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que
responde a las solicitudes.
1. Arquitecturas de sistemas de información
La arquitectura de un sistema informático se define como un subconjunto de reglas, normas y

procedimientos de tipo organizativo, aplicadas dentro de una organización, que especifican las
interrelaciones que deben existir entre los componentes y elementos, físicos y lógicos, de un
sistema informático y las características que deben cumplir cada uno de estos componentes para
que puedan interconectarse. (Un ejemplo es la arquitectura Systems Networks Architecture o SNA
de IBM).
1.1. Definición de un Sistema de Información
La arquitectura de un sistema de información define dicho sistema en términos de los componentes

y las interacciones entre estos componentes, desde el punto de vista de aspectos específicos del
sistema, basados en principios de estructuración específicos.
Un Sistema de Información (en adelante puede verse como S.I.) es un conjunto de procedimientos,
manuales y automatizados, y de funciones dirigidas a la recogida, elaboración, evaluación,
almacenamiento, recuperación, condensación y distribución de informaciones dentro de una
organización, orientado a promover el flujo de las mismas desde el punto en el que se generan
hasta el destinatario final de las mismas".
Debemos distinguir entre un sistema de información y un sistema informático. A veces se tiende a

utilizar indistintamente ambos términos, pero conceptualmente son bien distintos. Podemos
considerar un sistema informático como un conjunto de elementos que hacen posible el tratamiento
automatizado de la información. Se trata por tanto de un subconjunto del sistema de información.
1.2. Estructura de un Sistema de Información
Un S.I. completo para una organización es un instrumento enormemente complejo que está
constituido por un gran número de partes, o subsistemas, que interaccionan unos con otros en
grado diferente y cuya estructuración tiene simultáneamente una dimensión vertical y horizontal.
1.2.1. Estructura vertical
En su dimensión vertical el S.I. tiene distintos niveles jerárquicos:
• Nivel operacional: donde se manejan procedimientos de rutina relacionados con las

distintas actividades de la organización. En este nivel tiene lugar el grueso del tratamiento
de datos y el sistema mantiene vínculos estrechos con los procesos físicos realizados por
la organización.
Arquitecturas de sistemas de información
• Nivel táctico: donde se adoptan decisiones concretas, a corto plazo basadas en

información elaborada a partir de datos transaccionales o procedentes de fuentes externas
formalizadas. Las decisiones tomadas a nivel táctico se implementan generalmente a
través de la parte operacional del S.I. mediante un procedimiento automatizado en un S.I.
integrado o a través de medios más informales en otros casos.
• Nivel estratégico: se implementan decisiones más amplias, a mayor plazo, apoyadas

menos en información formal procedente de datos transaccionales y que dependen en gran
medida de fuentes de información externa.
1.2.2. Estructura horizontal
En su estructura horizontal, y dentro de cada uno de los niveles anteriores, las funciones se
subdividen en aplicaciones o procedimientos (subsistemas). Por ejemplo, el nivel operativo de una
empresa de fabricación incluiría subsistemas de pedidos, control de inventario, etc.
Estos subsistemas pueden estar directamente conectados unos con otros aportando un alto grado
de integración o por el contrario pueden estar concebidos bajo un enfoque separado o autónomo
que contempla cada aplicación o procedimiento de manera separada e independiente de los
restantes procedimientos de la organización. En cualquier caso, el grado de integración entre
subsistemas es una cuestión principal en el diseño de un S.I.
Un sistema integrado M.I.S. (Management Information System) es aquel que tiene un alto grado de
coordinación, con entradas y salidas rígidamente establecidas, teniendo en cuenta los efectos de
un subsistema sobre los otros y en el que los recursos son ampliamente compartidos.
Las principales ventajas de un enfoque integrado son las siguientes:
• Mayor eficiencia conjunta y una interrelación más efectiva de actividades entre

subsistemas.
• Compartición amplia de recursos que ofrece beneficios potenciales, debido a economías

de escala y especialización.
• Posibilidad de abordar las decisiones desde la perspectiva del sistema conjunto en vez de
sobre una base subóptima que utilice solamente información y objetivos locales.
Como contrapartida, el coste fundamental de la integración es la complejidad y riesgo añadidos.

Así pues, una cuestión fundamental en el diseño de un sistema es el equilibrio entre integración e
independencia.
1.3. Funciones básicas en un Sistema de Información
Dentro de la complejidad general de un sistema de información, las funciones realizadas dentro de

cada subsistema tienden a ser conceptualmente claras. Veamos cuales son los principales
aspectos de las funciones básicas de tratamiento de la información dentro del S.I.
• Entrada de datos.
Los datos entran al S.I. en forma de transacciones que describen sucesos del mundo real.
Los principales aspectos a considerar en relación con la entrada de datos son:
Técnicas más apropiadas (operación de teclado manual o reconocimiento óptico de

caracteres) a emplear y su coste.
Control de errores a través de procesos de verificación y edición.
Enfoque integrado capturando solamente una vez un elemento dado de datos y a

continuación compartirlo con todas las aplicaciones que lo necesitan.
Interactividad como medio para mejorar sustancialmente la eficacia y calidad de las

operaciones.
• Almacenamiento de datos.
El S.I. debe mantener grandes ficheros de datos destinados a suministrar la información

para el tratamiento de transacciones y para la toma de decisiones. Los principales
aspectos a considerar son:
Papel de la Base de datos en la organización a fin de que se mantenga como una

representación suficientemente fiable de la realidad.
Organización de la Base de datos de forma que se facilite el acceso a partes

específicas.
Almacenamiento en línea versus fuera de línea.
• Cálculo.
Mediante el cálculo el S.I. transforma los datos brutos en información utilizable por el
propio sistema o en forma ajena al mismo.
Como respuesta a la necesidad de cálculo prevista, el diseño de un S.I. debe contemplar la

necesaria potencia de tratamiento de los equipos soporte.
• Presentación de la información.
La función de presentación de un S.I. proporciona una conexión esencial, o interfaz, entre

el sistema y el usuario. Su finalidad es presentar la información de modo que mejore la
capacidad del usuario para percibir y actuar sobre los hechos reflejados por la información.
Uno de los aspectos más críticos en el diseño de un S.I. es la construcción del interfaz de
modo que el sistema proporcione la manera más eficaz de presentar los resultados a los
usuarios.
• Comunicaciones.
Los sistemas de información actuales se diferencian muy notablemente de los del pasado
en su creciente apoyo a las comunicaciones. Los avances experimentados en los sistemas
de información están estrechamente relacionados con los avances realizados en el mundo
de las telecomunicaciones.
Así hemos asistido a sistemas que dependían muy poco o nada de las telecomunicaciones
y donde los datos eran comunicados mediante transporte físico de medios de
almacenamiento. Más tarde pasamos al uso extendido de terminales de entrada de tareas
a distancia que no incorporaban ninguna capacidad de procesamiento. Ahora asistimos a la
implantación de sistemas informáticos distribuidos en los que los ordenadores de la
organización están conectados por medio de una red de telecomunicaciones, compartiendo
recursos y con capacidades de cálculo autónomo para servir a las necesidades
especializadas de sus usuarios.
1.3.1. Entrada de datos
Los datos entran al S.I. en forma de transacciones que describen sucesos del mundo real. Los
principales aspectos a considerar en relación con la entrada de datos son:
• Técnicas más apropiadas (operación de teclado manual o reconocimiento óptico de

caracteres) a emplear y su coste.
• Control de errores a través de procesos de verificación y edición.
• Enfoque integrado capturando solamente una vez un elemento dado de datos y a

continuación compartirlo con todas las aplicaciones que lo necesitan.
• Interactividad como medio para mejorar sustancialmente la eficacia y calidad de las

operaciones.
1.3.2. Almacenamiento de datos
El S.I. debe mantener ficheros de datos destinados a suministrar la información para el tratamiento
de transacciones y para la toma de decisiones. Los principales aspectos a considerar son:
• Papel de la Base de datos en la organización a fin de que se mantenga como una

representación suficientemente fiable de la realidad.
• Organización de la Base de datos de forma que se facilite el acceso a partes específicas.
• Almacenamiento en línea versus fuera de línea.
1.3.3. Cálculo
Mediante el cálculo el S.I. transforma los datos brutos en información utilizable por el propio
sistema o en forma ajena al mismo.
Como respuesta a la necesidad de cálculo prevista, el diseño de un S.I. debe contemplar la

necesaria potencia de tratamiento de los equipos soporte.
1.3.4. Presentación de la información
La función de presentación de un S.I. proporciona una conexión esencial, o interfaz, entre el

sistema y el usuario. Su finalidad es presentar la información de modo que mejore la capacidad del
usuario para percibir y actuar sobre los hechos reflejados por la información. Uno de los aspectos
más críticos en el diseño de un S.I. es la construcción del interfaz de modo que el sistema
proporcione la manera más eficaz de presentar los resultados a los usuarios.
1.3.5. Comunicaciones
Los sistemas de información actuales se diferencian muy notablemente de los del pasado en su
creciente apoyo a las comunicaciones. Los avances experimentados en los sistemas de
información están estrechamente relacionados con los avances realizados en el mundo de las
telecomunicaciones.
Así hemos asistido a sistemas que dependían muy poco o nada de las telecomunicaciones y donde
los datos eran comunicados mediante transporte físico de medios de almacenamiento. Más tarde
pasamos al uso extendido de terminales de entrada de tareas a distancia que no incorporaban
ninguna capacidad de procesamiento. Ahora asistimos a la implantación de sistemas informáticos
distribuidos en los que los ordenadores de la organización están conectados por medio de una red
de telecomunicaciones, compartiendo recursos y con capacidades de cálculo autónomo para servir
a las necesidades especializadas de sus usuarios.
1.4. El modelo centralizado
El modelo centralizado es el que sido ampliamente utilizado en los Sistemas de Información de las
grandes organizaciones en décadas anteriores, mediante un Host que ejecutaba el 100% de la
lógica del sistema, residiendo únicamente en el terminal de usuario las funciones de presentación.
A este tipo de aplicaciones, que concentran todas las lógicas funcionales del software
(presentación, negocio y acceso a datos) en un mismo componente se les denomina aplicaciones
monolíticas.
La principal ventaja de este modelo es que se dispone y se procesa toda la información en la

misma máquina física, con lo que el software del sistema es mucho más sencillo y fácil de
gestionar.
De las desventajas se puede nombrar su poca capacidad de crecimiento o escalabilidad, ya que

aunque los equipos que dan soporte a los mismos son de una capacidad extrema, una vez se llega
al límite de utilización del mismo, la única posibilidad de crecimiento es la adquisición y sustitución
por un nuevo equipo con más potencia y capacidad, con el agravante de que estos sistemas son
de los más caros del mercado.
Otro de los problemas de este modelo en su la poca capacidad de integración con otros sistemas
de información. Son prácticamente islas en los que la única posibilidad de intercambio de
información se hace por medio de procesos diferidos no on-line.
Otro defecto de estos sistemas son los relativos a la disponibilidad de los mismos, derivada
principalmente de la tolerancia a fallos que proporcionan ya que, a pesar de que los sistemas
mainframe son de los más robustos que se conocen, cuándo se produce un error en el sistema, el
sistema en su totalidad falla, haciendo que la disponibilidad en estos casos no sea la deseada.
1.5. Arquitecto de sistemas de información
Un arquitecto de sistemas de información diseña la arquitectura de un sistema de información. Esto

significa que planifica los elementos individuales del sistema de información, los implementa y, al
mismo tiempo, tiene la responsabilidad de mejorarlos. El arquitecto de sistemas de información es
para el sistema de información de una compañía lo que un arquitecto es para un edificio. Sin
embargo, es posible que el sistema de información cambie con el paso del tiempo.
Para realizar su tarea de manera correcta, en primer lugar, el arquitecto de sistemas de

información debe estudiar las necesidades del cliente (su administración o la organización que lo
contrató), en el caso de que ya disponga de un sistema de información, debe establecer una
cartografía mediante el análisis del mismo, proponer un modelo de arquitectura y por último,
hacerlo realidad mediante la elección de una infraestructura de hardware y software.
Un arquitecto de sistemas de información generalmente trabaja como parte de un equipo, en

colaboración, de ser necesario, con un ingeniero de sistemas y un ingeniero de redes, e interactúa
con las diferentes administraciones de la compañía.
La profesión del arquitecto de sistemas es sumamente estratégica respecto al ámbito de las

Tecnologías de la Información y que condiciona el funcionamiento de la compañía. Además de sus
habilidades técnicas, el arquitecto de S.I. debe tener dominio de la organización de la compañía y
de su infraestructura técnica, capacidad para trabajar en equipos multidisciplinarios,
relacionándose con distintos profesionales como diseñadores, desarrolladores de software, etc.,
capacidad analítica para estudiar otros sistemas de información y encontrar elementos positivos
que puedan ser susceptibles de incorporar, etc.
2. El procesamiento cooperativo
La concepción tradicional de las arquitecturas informáticas era centralizada y jerárquica. Poco a

poco se fue evolucionando a una concepción más abierta, en la que cada unidad en una
organización coordina sus propias actividades.
Con la proliferación de ordenadores personales de bajo coste en el mercado, los recursos de

sistemas de información existentes en cualquier organización se pueden distribuir entre
ordenadores de diferentes tipos: ordenadores personales de gama baja, media y alta, estaciones
de trabajo, miniordenadores o incluso grandes ordenadores.
El procesamiento cooperativo es aquel en que dos o más elementos lógicos diferentes interactúan
entre sí en la realización de una tarea común.
De una forma más extensa, el concepto de procesamiento cooperativo consiste en un conjunto de

ordenadores que ejecutan una misma aplicación. Normalmente un host y varios microordenadores
que comparten la ejecución de un proceso global.
De forma más amplia, el procesamiento cooperativo es el que utiliza plataformas software y

hardware de diferentes suministradores como soporte para la ejecución de una aplicación global.
El modelo convencional utiliza el host para ejecutar el 100% de la lógica asociada a un programa,
residiendo únicamente en el terminal de usuario las funciones de presentación. Las ventajas del
procesamiento cooperativos frente al modelo convencional, se derivan de la utilización eficiente de
los equipos microordenadores y la consiguiente descarga de tareas del ordenador central.
Existen diferentes modelos para el desarrollo de aplicaciones que reparten procesos y datos en
distintos ordenadores. A continuación se describen los más característicos.
2.1. Procesamiento distribuido
Se distribuyen en la red de miniordenadores los tratamientos correspondientes a la parte

interactiva de la aplicación. Habitualmente responde al siguiente esquema de tratamiento:
• Durante el día funciona la aplicación interactiva de modo autónomo utilizando información

cargada en sus propios discos, como elementos de contraste y validación.
• Al cierre diarios, primero se hacen los procesos batch locales.
• Durante la noche, se transfieren los datos consolidados durante la jornada al host, donde
se aplican a la base de datos corporativa mediante procesos batch.
• Al acabar los procesos batch del host, se distribuyendo los datos necesarios a los equipos
locales como soporte de funcionamiento en la jornada siguiente.
En estos sistemas es habitual que el desarrollo se realice de forma centralizada, lo que implica
también la distribución periódica de las nuevas versiones de software para la actualización de
aplicativos.
2.2. Bases de datos distribuidas
Son aquellas en que sus datos se distribuyen por los diferentes equipos del sistema con criterios
de eficacia, acercamiento al usuario que en mayor grado los utiliza, gobernado por el propio gestor
de la base de datos de modo que la residencia de los distintos elementos es transparente al
diseñador del desarrollo de aplicaciones y al usuario final.
2.3. Procesamiento cooperativo
El procesamiento cooperativo, propiamente dicho, se entiende como el que utiliza de forma

eficiente todos los recursos de cada plataforma hardware y software del sistema, estableciéndose
un diálogo e intercambio de servicios entre las mencionadas plataformas, para dar como resultado
la ejecución de un aplicativo global.
La arquitectura de computación distribuida, también conocida como “de procesamiento

cooperativo” consiste en el desarrollo de una aplicación dividida en componentes más o menos
autónomos que se ejecutan en unidades de hardware interconectadas por redes de alta velocidad.
El procesamiento cooperativo es aquel en que dos o más elementos lógicos diferentes interactúan
entre sí para la realización de una tarea común. Surgió para intentar dar respuesta a los problemas
y debilidades del modelo centralizado, aunque este modelo tiene sus propios problemas derivados
por su propia naturaleza distribuida.
Existen diferentes definiciones del concepto de "sistema distribuido":
• “Un sistema distribuido es aquel en el cual varios procesadores autónomos y repositorios

de datos que soportan procesos y/o bases de datos, interactúan con el fin de cooperar
para lograr un objetivo global. Los procesos coordinan sus actividades e intercambian
información por medio de la transferencia de información a través de una red de
comunicación”, Sloman & Kramer, 1987. De esta definición se pueden comenzar a sacar
distintas conclusiones, como por ejemplo la idea de la utilización de un conjunto de
recursos distribuidos para la realización de un trabajo común. Esta idea se ve refrendada
por otras definiciones.
• “Un sistema distribuido es una colección de computadoras independientes que aparece

ante los usuarios del sistema como una única computadora”, Tanenbaum, 1995. La
definición de Tanenbaum establece la idea de sistema distribuido como la forma de ofrecer
un servicio único a los usuarios a partir del uso de un conjunto de computadoras totalmente
independientes.
Los sistemas distribuidos pretenden alcanzar un estilo arquitectónico que habilite tres cualidades:
• Integrabilidad: de datos y aplicaciones.
• Modificabilidad: de aplicaciones, de representación de los datos, de ubicación física de los

componentes (separación de funciónes en presentación, negocio y acceso a datos).
• Escalabilidad: si la organización crece el sistema debe acompañar y permitir el crecimiento

de forma transparente para las unidades que ya están en producción.
3. La arquitectura cliente – servidor
La arquitectura cliente - servidor (en adelante puede verse como cliente/servidor o C/S) permite
estructurar sistemas distribuidos con componentes desacoplados que interactúan por medio de
invocaciones remotas a servicios.
La arquitectura cliente/servidor es una forma de dividir y especializar programas y equipos de

cómputo de forma que la tarea que cada uno de ellos realiza se efectúa con la mayor eficiencia
posible y permita simplificar las actualizaciones y mantenimiento del sistema.
3.1. Definiciones
Con respecto a la definición de arquitectura cliente/servidor se encuentran las siguientes

definiciones:
• Cualquier combinación de sistemas que pueden colaborar entre sí para dar a los usuarios
toda la información que ellos necesiten sin que tengan que saber dónde está ubicada.
• Es una arquitectura de procesamientos cooperativo donde uno de los componentes pide

servicios a otro.
• Es un procesamiento de datos de índole colaborativo entre dos o más computadoras

conectadas a una red.
• El término cliente/servidor es originalmente aplicado a la arquitectura de software que

describe el procesamiento entre dos o más programas: una aplicación y un servicio
soportante.
• IBM define al modelo cliente/servidor: "Es la tecnología que proporciona al usuario final el
acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro
recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. El

modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio
hechos por estaciones de trabajo inteligentes o "clientes'', resultan en un trabajo realizado
por otros computadores llamados servidores".
• Es un modelo para construir sistemas de información, que se sustenta en la idea de

repartir el tratamiento de la información y los datos por todo el sistema informático,
permitiendo mejorar el rendimiento del sistema global de información.
3.2. Concepto de la arquitectura cliente/servidor
La tecnología cliente/servidor es el procesamiento cooperativo de la información por medio de un

conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan
requerimientos a uno o más servidores centrales.
Desde el punto de vista funcional, se puede definir la computación cliente/servidor como una
arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma
transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en
la realización de sistemas distribuidos.
Un sistema cliente/servidor es un sistema de Información distribuido basado en las siguientes

características:
• Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.
• Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos,
comparten tanto recursos lógicos como físicos.
• Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su

establecimiento pasivamente.
• Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué
saber dónde se encuentra situado el recurso que desea utilizar.
• Independencia de la plataforma hardware y software que se emplee.
• Sistemas débilmente acoplados. Interacción basada en envío de mensajes.
• Encapsulamiento de servicios. Los detalles de la implementación de un servicio son

transparentes al cliente.
• Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores).
• Integridad: Datos y programas centralizados en servidores facilitan su integridad y

mantenimiento.
En el modelo usual cliente/servidor, un servidor, (daemon en la terminología sajona basada en

sistemas UNIX/LINUX, traducido como "demonio") se activa y espera las solicitudes de los clientes.
Habitualmente, programas cliente múltiples comparten los servicios de un programa servidor
común. Tanto los programas cliente como los servidores son con frecuencia parte de un programa
o aplicación mayores.
El esquema de funcionamiento de un sistema cliente/servidor sería:
• El cliente solicita una información al servidor.
• El servidor recibe la petición del cliente.
• El servidor procesa dicha solicitud.
• El servidor envía el resultado obtenido al cliente.
• El cliente recibe el resultado y lo procesa.
La arquitectura cliente/servidor en 2 niveles o 2 capas (figura 1) se utiliza para describir los

sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a
la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicación para
proporcionar parte del servicio. Esta arquitectura sigue siendo muy utilizada en la actualidad y
fueron las primeras en aprovecharse de la estructura cliente/servidor.
Figura 1. Arquitectura cliente/servidor en 2 niveles
En la arquitectura en 3 niveles (figura 2), existe un nivel intermedio. Esto significa que la
arquitectura generalmente está compartida por:
• Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de
usuario (generalmente un navegador Web) para la presentación.
• El servidor de aplicaciones (también denominado software intermedio), cuya tarea es

proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo.
• El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere.
Figura 2. Arquitectura cliente/servidor en 3 niveles
3.3. Elementos principales
"Los elementos principales de la arquitectura cliente servidor son justamente el elemento llamado
cliente y el otro elemento llamado servidor". Por ejemplo dentro de un ambiente multimedia, el
elemento cliente seria el dispositivo que puede observar el vídeo, cuadros y texto, o reproduce el
audio distribuido por el elemento servidor.
Por otro lado el cliente también puede ser una computadora personal o una televisión inteligente
que posea la capacidad de entender datos digitales. Dentro de este caso el elemento servidor es el
depositario del vídeo digital, audio, fotografías digitales y texto y los distribuye bajo demanda de
ser una máquina que cuenta con la capacidad de almacenar los datos y ejecutar todo el software
que brinda éstos al cliente.
3.3.1. Cliente
Un cliente es todo proceso que reclama servicios de otro. Una definición un poco más elaborada
podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y
pasarlos al servidor. Se lo conoce con el término front-end.
Éste normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de
datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas
de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de la red. Las
funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
• Administrar la interfaz de usuario.
• Interactuar con el usuario.
• Procesar la lógica de la aplicación y hacer validaciones locales.
• Generar requerimientos de bases de datos.
• Recibir resultados del servidor.
• Formatear resultados.
La funcionalidad del proceso cliente marca la operativa de la aplicación (flujo de información o

lógica de negocio). De este modo el cliente se puede clasificar en:
• Cliente basado en aplicación de usuario. Si los datos son de baja interacción y están
fuertemente relacionados con la actividad de los usuarios de esos clientes.
• Cliente basado en lógica de negocio. Toma datos suministrados por el usuario y/o la base
de datos y efectúa los cálculos necesarios según los requerimientos del usuario.
3.3.2. Servidor
Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de

atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso
servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las
funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las
principales funciones que lleva a cabo el proceso servidor se enumeran a continuación:
• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.
Puede darse el caso que un servidor actúe a su vez como cliente de otro servidor. Existen
numerosos tipos de servidores, cada uno de los cuales da lugar a un tipo de arquitectura
cliente/servidor diferente.
El término "servidor" se suele utilizar también para designar el hardware, de gran potencia,
capacidad y prestaciones, utilizado para albergar servicios que atienden a un gran número de
usuarios concurrentes. Desde el punto de vista de la arquitectura cliente/servidor y del
procesamiento cooperativo un servidor es un servicio software que atiende las peticiones de

procesos software clientes.
3.3.3. Middleware
El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a
cualquier usuario de sistemas de información comunicarse con varias fuentes de información que
se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el
cliente y el servidor y se ejecuta en ambas partes.
La utilización del middleware permite desarrollar aplicaciones en arquitectura cliente/servidor

independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando
dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo.
Los primeros “monitores de teleproceso” de los grandes sistemas basados en tecnología
cliente/servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en
sistemas abiertos cuando el concepto de middleware toma su máxima importancia. El middleware
se estructura en tres niveles:
• Protocolo de transporte.
• Network Operating System (NOS).
• Protocolo específico del servicio.
Las principales características de un middleware son:
• Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos

propietarios.
• Permite la interconectividad de los Sistemas de Información del organismo.
• Proporciona mayor control del negocio al poder contar con información procedente de
distintas plataformas sobre el mismo soporte.
• Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.
Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria
para que puedan funcionar.
3.4. Componentes de la arquitectura cliente/servidor
El modelo cliente/servidor es un modelo basado en la idea del servicio, en el que el cliente es un

proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Además esta
relación está establecida en función del intercambio de mensajes que es el único elemento de
acoplamiento entre ambos.
De estas líneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e
implantan los sistemas cliente/servidor: el proceso cliente que es quien inicia el diálogo, el proceso
servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que
corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder
intercambiar mensajes.
Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta
tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición
principalmente consiste en separar los elementos estructurales de esta tecnología en función de
aspectos más funcionales de la misma:
• Nivel de presentación: Agrupa a todos los elementos asociados al componente cliente.
• Nivel de aplicación: Agrupa a todos los elementos asociados al componente servidor.
• Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación
entre los componentes cliente y servidor.
• Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.
Este modelo de descomposición en niveles, como se verá más adelante, permite introducir más
claramente la discusión del desarrollo de aplicaciones en arquitecturas de hardware y software en
planos.
(1) Pressman, Roger S. (1999). Ingeniería del software, un enfoque práctico. Ed Mc Graw Hill.
(2) Coulouris, George. (2001). Sistemas Distribuidos. Ed Addison Wesley.
(3) Rodríguez, José Manuel; Daureo, María José. (2003). Sistemas de información: Aspectos
técnicos y legales. Universidad de Almería.
(4) Martos, Fernando; Desongles, Juan; Garzón, Mª Luisa; (2006). Técnicos de Soporte
Informático. Ed MAD.
Tema 25. Arquitectura SOA
Sara Blanc Clavero

Colegiada 0882
Este capítulo desarrolla contenido sobre la arquitectura SOA o arquitectura orientada a

servicios (System Oriented Architecture).
En la actualidad disponemos de una estandarización reciente, de 2016, conocida

como ISO/IEC 18384 “Reference Architecture for Service Oriented Architecture” donde
se define el término SOA como una arquitectura de referencia (1)(2)(3). No se trata,
por tanto, de una descripción tecnológica, sino de un estilo de diseño orientado a
servicios con el objetivo de conseguir una mayor agilidad en la planificación e
implementación de soluciones a necesidades empresariales, apertura en la
reutilización de recursos y federación en la unificación de criterios. Si lo que buscamos
es un método a bajo nivel o una solución tecnológica concreta, este estándar no es la
respuesta. El estándar trata de aglutinar fundamentos, principios y usos, y en esa
línea sigue este capítulo.
Desde mediados de los años 2000, se ha mantenido un debate muy intenso sobre cuál
debería ser el modelo de referencia de una arquitectura orientada a servicios. En la
norma, podemos encontrar influencia de todos los actores que han participado en la
definición y expansión del paradigma SOA. Como referencias para enriquecer los
conocimientos sobre SOA del estudiante, destacaremos el trabajo de Thomas Erl
(4)(5) y otros autores (6)(7), las numerosas publicaciones en abierto sobre el tema de
importantes compañías tecnológicas (8)(9)(10)(11) y por supuesto, también son de
gran relevancia los trabajos de investigación internacionales (12).
Si la pregunta es a qué área TI afecta este estándar, la respuesta es que a todas. No

sólo a desarrollo de software, sino también a sistemas, a gestión empresarial y
gobierno. La arquitectura SOA es un modelo de innovación empresarial que escala el
tratamiento de la información verticalmente desde los sistemas empresariales hasta
los usuarios finales. No crea conexiones directas entre sistema y usuario, sino que
incorpora un componente nuevo intermedio denominado servicio. Un servicio es una
abstracción del potencial empresarial y la efectividad de su uso depende de la
capacidad de desvincular facetas o detalles técnicos al propósito inherente del
servicio. Cuanto más agnóstica sea la conceptualización o lógica del servicio con
respecto a la tecnología o sistemas sobre los que se asienta, mayor será el grado de
reutilización del servicio o uso del servicio por parte de tareas vinculadas con los
procesos empresariales, y mayor será el grado de transparencia entre las tecnologías
actuales de los sistemas y la cobertura TI a las necesidades futuras del negocio. Este
principio es el que boga a favor de la agilidad y facilidad en la expansión de las
capacidades TI, cambio y adaptación a nuevas tecnologías y sistemas, y sobre todo, a
Sara Blanc Clavero
favor del crecimiento de los procesos empresariales alineados con los objetivos de
negocio.
Finalmente, no desvinculemos el futuro de SOA de otros términos ya bien conocidos

como son IoT (Internet of Things o Internet de las cosas) o Cloud Computing (13), ya
que todos reman hacia un mismo futuro, el de la interoperabilidad entre sistemas
creando ecosistemas múltiples y potenciando el intercambio de información entre
diferentes propietarios.
1. Fundamentos de la arquitectura SOA
La arquitectura SOA está basada en el diseño de servicios atendiendo a las necesidades de

negocio. Cada servicio se define como una representación lógica de un conjunto de acciones
repetibles, secuenciadas según unas reglas y condiciones, que producen una respuesta. Esta
lógica puede ser muy sencilla, o puede requerir un proceso de composición. Los servicios se
pueden componer entre sí para formar servicios compuestos. Los servicios compuestos reciben
información procesada por servicios más sencillos, con incluso diferente origen o tipo, y producen
información más elaborada y cercana a un propósito final.
Si la estructuración de la arquitectura y el diseño de los servicios están bien hechos, la gran

ventaja de la arquitectura SOA es que un mismo servicio puede tener múltiples aplicaciones, no
siendo necesario replicar su implementación una y otra vez. Simplemente, se usa.
Para ello, y como iremos viendo en el capítulo, un servicio debe poder ser descrito de una forma
convencional, entendible por otros. Además, un servicio también debe ser descubrible, ya que si se
mantiene oculto no puede ser utilizado. En resumen, los principios básicos son:
• Un servicio debe ser auto-contenido y tener control sobre su propia lógica, minimizando las
interdependencias entre servicios.
• La lógica de un servicio es transparente fuera del servicio. Significa que existe un nivel de
abstracción que sólo requiere conocimiento sobre la descripción del servicio (tipo caja
negra).
• Por tanto, los servicios no mantienen, o apenas mantiene, información específica sobre su
estado.
• Existe comunicación entre servicios (intercambio de datos). Los términos de la

comunicación se establecen a través de lo que conoceremos como “contrato”.
• Cuando un servicio envía un mensaje con información (datos), pierde el control sobre el
mismo. Así que los mensajes también son componentes o unidades dentro del proceso de
comunicación SOA.
Arquitectura SOA
• Un servicio puede tener más de un contrato (da servicio a más de un subscriptor o

consumidor del servicio).
• Los servicios se pueden componer en otros servicios compuestos más complejos en

cuanto al tratamiento de información se refiere.
• Los servicios son descubribles y por tanto, implementan mecanismos de descubrimiento.
Si estos son los principios básicos, las primeras preguntas que nos hacemos son ¿cómo se debe
planificar los servicios? o ¿cómo entendemos la relación entre servicios? En general, el diseño de
una arquitectura orientada a servicios nos debería llevar a reflexionar y analizar aspectos como:
• Identificar los procesos de negocio y las tareas que implican. Esas tareas se sostienen
sobre servicios compuestos sustentados por otros servicios más simples (flecha A Figura
1).
• Entender y crear las adaptaciones necesarias entre los sistemas empresariales y los
servicios de más bajo nivel (flecha B Figura1).
• Planificar servicios compuestos que den solución a los procesos empresariales y que se
sostengan sobre servicios más simples que describan atómicamente las capacidades de
los sistemas empresariales (conjunción de flechas “middle-out” Figura 1).
Estos puntos son los que representamos en la Figura 1.
Tarea
Procesos de
negocio
A
Servicio
Composición orientado al
de servicios negocio
Acceso a proveedor
externo al dominio
Servicios
atómicos Adaptadores
B
Sistemas
empresariales
Figura 1. Desde los sistemas empresariales hasta los procesos de negocio
Sara Blanc Clavero
1.1. Concepto de consumidor y proveedor de servicios
Los roles básicos que explican la relación entre servicios son el de proveedor de servicios y el
consumidor de servicios. En la Figura 2 vemos estos dos roles: proveedor y consumidor. En la
parte más baja de la arquitectura SOA, el proveedor del servicio, y la parte más alta de la
estructura, el consumidor. Estos consumidores de servicios presentan un abanico muy amplio de
posibilidades, desde aplicaciones de visualización de datos, de análisis gráfico, de seguimiento,
estadísticas, o herramientas complejas como Business Intelligence (BI). Entre ambos se definen
las capas intermedias de servicios y servicios compuestos. Cuanto más abajo en la Figura 1 se
encuentra un servicio, más desligado deberá estar de los procesos de negocio de las capas
superiores y más relacionado con los sistemas empresariales, por ejemplo, implementando
adaptadores o conectores entre el sistema empresarial y el bus empresarial. Mientras que a
medida que subimos en la estructura más desligados estarán de los sistemas empresariales y
centrados en los procesos de negocio. Si el servicio es útil a varios de estos procesos es un
proceso que facilita la composición y estaremos más cerca del paradigma SOA que si
implementamos servicios específicos para cada proceso, lo que irá en contra de las ventajas de
una arquitectura flexible y que potencia la oportunidad y la expansión.
Consumidor
de servicios
Servicio
• ERP, CRM, SCM, etc.

Proveedor • Sistemas industriales
de servicios • Sistemas de sensorización
y un largo etc.
Figura 2. Los dos roles básicos de la arquitectura SOA: consumidor y proveedor
Un servicio puede no requerir de inputs provenientes de otros servicios, mientras que los servicios
compuestos son consumidores de otros servicios que se ofertan como proveedores (Figura 3).
Arquitectura SOA
Servicio
Consumidor
Servicio Servicio
Proveedor 1 Proveedor 2
Figura 3. Los servicios como consumidores y proveedores para otros servicios compuestos
1.2. Principios básicos SOA
Para que esta estructura de composición funcione, la arquitectura SOA define unos principios
básicos que la sostienen. En general, los principios son los siguientes:
• Interoperabilidad o capacidad para intercambiar información entre servicios heterogéneos y

no siempre pertenecientes al mismo sistema. La visión más amplia de la arquitectura SOA
identifica diferentes dominios interconectados que pueden comunicarse soportados por la
estandarización y la convergencia entre protocolos.
• Descripción. Todo servicio debe poder ser descrito de una forma útil para poder publicarse
convenientemente y así establecer contratos.
• Reutilizable tanto por su interfaz como por la descripción del servicio que debe posibilitar la
multiplicidad de contratos.
• Descubrible, o lo que es lo mismo, que se pueda conocer su existencia y localizar dentro

un sistema. Veremos luego que el descubrimiento se posibilita a través del registro de
servicios.
• Que facilite la composición. Se facilita si el servicio mantiene el principio de reutilización,

donde la información de salida de un proceso puede utilizarse como entrada en otros
procesos, en plural, tanto actuales como futuros procesos que aún no existen ya que no se
ha presentado aún la necesidad de implementarlos.
• Auto-contenido y sin dependencias operativas o mínimas. Los servicios se diseñan para

intercambiar información y no se diseñan para que su ejecución dependa una de otra
generando bloqueos o cuellos de botella.
• Gestionable. Significa que los servicios deben ser diseñados como soluciones dinámicas,
que permitan su control, configuración, y mejora dentro de las reglas establecidas por el
gobierno.
Sara Blanc Clavero
1.3. La relación entre consumidor y proveedor
La relación entre un consumidor y un proveedor se establece a través de un contrato en el que se

describen las características del servicio subscrito. Una relación implica que va a existir un
intercambio de mensajes entre proveedor y consumidor. Pero el responsable del contrato puede
ser una tercera entidad implicada: el proveedor contractual o bróker (Figura 4). A modo de gestor o
agente, esta entidad es la que establece las relaciones contractuales y asume la responsabilidad
de publicación del servicio y del intercambio de mensajes. Está claro, además, que para que exista
una relación entre servicios los mensajes deben asegurar la interoperabilidad sintáctica en sus
formatos, y la semántica en sus contenidos.
Servicio
Consumidor
Servicio
Servicio
Proveedor
Proveedor
del contrato
Figura 4. La figura del proveedor contractual (o bróker del servicio)
El consumidor de un servicio es, por su parte, quien debe descubrir el servicio o servicios que le
interesan e invocarlos para iniciar el intercambio de mensajes cara a establecer el contrato. Hay
tres principios sobre la relación proveedor-consumidor en la arquitectura SOA:
• Independencia de dominios. Tanto proveedor como consumidor pueden ser parte del
mismo sistema o de diferentes sistemas. El principio de interoperabilidad previene la falta
de entendimiento en caso de la deslocalización de los servicios.
• Independencia de plataformas de desarrollo. Cada servicio actúa como una caja negra de
cara al resto de servicios siendo transparente al consumidor la plataforma, lenguaje y otros
componentes relacionados con la implementación que sustenten el servicio.
• Independencia de protocolos de mensajería. De nuevo, el principio de interoperabilidad

establecido en la arquitectura debe proveer de mecanismos para la transformación de los
mensajes a los formatos adecuados sin que esto corresponda a los propios servicios,
pudiendo así un proveedor establecer un contrato con distintos consumidores que actúen
sobre distintas plataformas.
Entonces ¿cuál es la diferencia entre servicios SOA y servicios Web? (14) Si bien los protocolos y
estándares existentes para servicios web se pueden aplicar y se ha aplicado en numerosas
ocasiones al desarrollo de servicios SOA por sus facilidades en la publicación e invocación de
servicios así como en la interoperabilidad entre plataformas, no todos los servicios web se han
Arquitectura SOA
diseñado atendiendo a todos los principios SOA. No existe una reciprocidad directa, pero sí
comparten muchos principios fundamentales.
Siguiendo con el tándem proveedor-consumidor, para que un consumidor pueda descubrir

servicios sobre un sistema, el registro de servicios es una parte fundamental de la arquitectura
SOA (Figura 5). Un servicio se registra utilizando su descripción. El mantenimiento de este registro
es parte de las obligaciones del gobierno de TI quien deberá establecer los mecanismos tanto de
control de acceso al registro como sobre las acciones de gestión del registro incluyendo la
definición de la forma descriptiva, el aseguramiento en la coherencia y cohesión de los
descriptores, la inclusión de nuevos servicios, su clasificación e eliminación del registro o la
modificación y actualización de su descripción.
Servicio
Consumidor
Descubrimiento (petición) Descubrimiento (respuesta)
Registro (petición)
Registro de Servicio
servicios Proveedor
Registro (respuesta)
Figura 5. El concepto de Registro de Servicios
Por tanto, ¿qué componentes tendrá un servicio? Para ser compatible con la arquitectura SOA un
servicio se compone de tres partes fundamentales que son: su lógica, su descripción y su
interfaz.
1) La lógica siempre es única e identifica plenamente al servicio. A la lógica le podríamos añadir

también, y deberíamos, la calidad de servicio haciendo referencia así no sólo a su funcionalidad (o
alcance funcional) sino a la globalidad de sus requisitos, tanto funcionales como no funcionales. Un
requisito no funcional especifica características relativas a la operación de un sistema como, por
ejemplo, características de usabilidad, disponibilidad, seguridad, fiabilidad, etc. (ver ISO/IEC 9126).
2) Por otra parte, la descripción de un servicio podría y debería ser única: una descripción identifica
a un único servicio. Esta característica está vinculada a los principios de reutilización y de lógica
agnóstica. Quiere decir, que la lógica define el propósito del servicio, despojándose de cualquier
referencia a tecnologías o “detalles técnicos”. Cuanto mayor sea el nivel de abstracción en la lógica
del servicio más potenciaremos dos ventajas. Primera, será posible modificar la componente
tecnológica del servicio (protocolos, lenguajes, etc.) sin modificar su descripción. Segunda, mayor
provecho se le podrá dar a este servicio ya que con la misma descripción será útil para una
multiplicidad de consumidores potenciales.
Sara Blanc Clavero
3) En cuanto a la interfaz, está claro que en algún sitio debe residir la convergencia entre
protocolos. Es recomendable que esta convergencia ocurra en una capa de integración,
transversal a toda la arquitectura, aunque está claro que siempre existirá una vinculación entre las
interfaces de los servicios y los principios de integridad.
Por encima de los servicios, ya sean simples o compuestos, y de sus relaciones se definen las
tareas. Una tarea es una acción atómica realizada normalmente a instancias de un actor humano.
La composición de tareas implementa procesos de negocio, a veces simples como una
secuenciación de tareas, a veces complejos con bifurcaciones condicionales. En el estándar ISO
18384 se diferencian tres estilos de composición de tareas: orquestación, coreografía y
colaboración.
• La orquestación implica un flujo de tareas (workflow) gestionada por un elemento externo a

la composición, el orquestador. Este “director de la orquesta” es el encargado de
establecer la secuencia orquestada de ejecución de tareas que puede estar condicionada a
variables como el tiempo o la ocurrencia de eventos externos o de la propia secuencia.
• La coreografía no orquesta flujos de tareas sino establece relaciones entre tareas mediante
patrones de intercambio de datos. Por ejemplo, a modo de diagrama de relaciones, los
datos generados por una tarea pueden identificarse de un tipo determinado establecido
como tipo de entrada de otras tareas relacionadas pero sin que esto suponga
necesariamente una secuencialización entre la tarea generadora y la receptora. Al igual
que antes, la coreografía también es gestionada por un elemento externo al proceso.
• Finalmente, la colaboración no es gestionada por ningún elemento externo sino que se

define como la compatibilidad entre tareas, dejando que estas se ejecuten de manera
independiente estableciéndose relaciones puntuales, si fuera necesario, entre algunas de
ellas si tienen capacidad para ello. Esta relación es la más alejada de un buen
planteamiento SOA.
2. Modelo de referencia SOA
El modelo de referencia de la arquitectura SOA es independiente de cualquier implementación

tecnológica. Aunque más adelante veremos que hay tendencias, cualquier implementación debería
seguir el modelo que aquí estudiamos: un modelo en 9 capas.
2.1. Arquitectura de capas
En la Figura 6 vemos que hay 5 capas que se sostienen de forma vertical, mientras que las otras 4
son transversales a toda la arquitectura.
Arquitectura SOA
Capa del consumidor
Información
Integración
Gobierno
Capa de los procesos de negocio
QoS
Capa de servicios
Capa de componentes
Capa de operatividad
Figura 6. Capas de la arquitectura SOA
Capa 1 o de operatividad. Esta capa incluye los sistemas operacionales que existan o puedan
existir ya en el entorno TI empresarial. Incluye sistemas empresariales, sistemas transaccionales,
bases de datos, sistemas industriales, sistemas de sensorización, etc.
Capa 2 de componentes. Es la capa de abstracción de los sistemas operacionales a la capa de

servicios. Transforma el operativo en lógica, desvinculando el servicio de la tecnología concreta,
protocolo o técnica del sistema operacional. Esta capa debe de prevenir la redundancia de
componentes, pudiendo agrupar un mismo componente (que realmente ya es un servicio) la lógica
de varios sub-sistemas. Como ventaja, los sistemas de la capa 1 podrán mejorarse, cambiarse y
sufrir transformaciones sin que los servicios existentes deban modificarse. Si el cambio además
supone agregar una nueva funcionalidad, se podrán definir nuevos servicios en esta capa para
integrar dicha funcionalidad en los procesos de negocio.
Capa 3 de servicios. Esta capa puede verse como un conjunto de sub-capas, tal como se
representa en la Figura 1. Los servicios pueden subir en complejidad en función del tratamiento y
procesamiento de la información. Por ejemplo, los servicios más bajos en esta capa pueden
explotar las funcionalidades derivadas de la capa 2 de manera atómica, mientras que en servicios
superiores se procesa la información agregando, cruzando o combinando datos de servicios del
entorno empresarial y externos.
Capa 4 de procesos de negocio. Un proceso de negocio es una representación TI de varias

actividades (tareas) coordinadas con un objetivo de negocio. En esta capa los procesos pueden
ser orquestados o coreografiados. Los datos y la información fluye en etapas y genera respuestas
que interesan al consumidor: la capa por encima de ésta.
Capa 5 del consumidor. Algunos autores la identifican como de visualización, aunque el estándar
es más amplio y generaliza a cualquier aplicación especializada sobre los procesos de negocio. El
objetivo de esta capa es normalizar el método de acceso a los datos procesados con el fin de
poder generar rápidamente los front-end de visualización, interacción y explotación de resultados.
Sara Blanc Clavero
Capa 6 de integración. Esta capa debe implementar en la arquitectura la capacidad de proveer.

Se basa en tres principios: mediación, enrutamiento y transformación (de datos/formatos). Además,
es en esta capa donde se mantiene el registro de servicios. La capa de integración también
controla aspectos no funcionales de la transferencia entre capas tales como la latencia. Una
representación de esta capa es el ESB (Enterprise Service Bus o Bus de Servicio Empresarial) que
proporciona facilidades para la implementación de la arquitectura. Aunque no necesariamente
complejo, este middleware debe estar orientado a agilizar la creación de servicios y contratos y
reducir el acoplamiento entre el servicio provisto y el medio de transporte para que los mensajes
sean unidades independientes del servicio.
Capa 7 de QoS. Esta capa proporciona las facilidades necesarias para sostener los requisitos no
funcionales de la arquitectura conocidos también por requisitos de calidad. Si ponemos algunos
ejemplos de estos requisitos podemos nombrar la seguridad, fiabilidad, robustez, estabilidad,
usabilidad, testabilidad, mantenimiento, documentación, escalabilidad, etc.
Capa 8 de información. Esta capa debe asegurar la representación y tratamiento de datos e

información bajo las directrices de la arquitectura SOA. Por eso, en cada capa de las que hemos
visto hasta ahora hay una pieza de esta capa que se extiende transversalmente.
Capa 9 de gobierno. Es la capa de responsabilidad sobre la definición de la arquitectura, su

diseño, creación e implementación de servicios, mantenimiento y sostenibilidad del sistema
empresarial resultante.
A modo de referencia, el estándar propone una relación entre competencias y requisitos que
definen las capas que hemos descrito y bloques de implementación que las soportan (Figura 7).
Adoptar SOA debe ser estratégico y no un capricho. La adopción de SOA viene motivada unas
necesidades organizativas claramente identificadas. Por tanto, el alcance de la solución SOA que
se plantee se podrá definir en base a los requisitos identificados en respuesta a esas necesidades.
La capacidad empresarial y tecnológica de la organización restringen o limitan la adopción de
soluciones. Soluciones que describen las capacidades esperadas de la arquitectura a implantar.
Siguiendo con la figura, estas capacidades se modelan en elementos concretos sobre las capas de
la Figura 6: los bloques a construir por capa. Los bloques de implementación son los distintos
módulos que soportan las expectativas definidas en cada capa así como las interfaces de conexión
entre capas.
Arquitectura SOA
Soportadas por las

Capacidades TI Capacidades empresariales
Definición de
Asumir
Consolidadas sobre
Necesidades (requisitos) Capacidades de la arquitectura
Diseño de
Implementación de
Bloques a construir por capa Capas de la arquitectura
Figura 7. Relación entre competencias, requisitos, capas y bloques de implementación.
2.2. Ciclo de vida de un servicio SOA
El ciclo de vida SOA de un servicio tiene varias etapas que se asemejan al waterflow de las fases
del desarrollo de software, por ejemplo, podrían ser: definición, modelado, implementación,
verificación del servicio, ensamblaje con el sistema, validación sobre el sistema y mantenimiento.
Sin embargo, el ciclo de vida no se define con una temporalidad finita, sino como un ciclo vivo y
enlazado con el ciclo de mejora continua del sistema empresarial.
Extendiendo este modelo reducido del ciclo de vida, el SOA School (15) propone 10 etapas
concretas gestionadas por el gobierno de SOA. Las etapas son:
• Análisis de inventario. Cuál es el alcance de nuestro inventario actual, cuáles son las
prioridades y cómo evitamos desde el inicio la duplicidad, redundancia o ambigüedad de
servicios para ahorrar tiempo y costes en las siguientes etapas.
• Análisis y modelado del servicio, incluyendo la identificación de composiciones y utilidad

del servicio.
• Diseño del contrato que se asociará a la provisión de este servicio.
• Diseño de la lógica del servicio, incluyendo el control del acceso al servicio.
• Desarrollo o implementación del servicio.
• Testeo de los requerimientos funcionales y no funcionales del servicio.
• Revisión del desarrollo, validación sobre la arquitectura, certificación y aseguramiento de

las reglas de mantenimiento.
Sara Blanc Clavero
• Lanzamiento de la monitorización del servicio.
• Publicación del servicio en el registro de servicios.
• Revisión de versiones y mejora continua.
2.3. Ecosistemas SOA
La participación en ecosistemas SOA se centra en cómo las organizaciones empresariales

atienden sus necesidades (Figura 7) en un sistema plural con múltiples dominios, donde cada
dominio puede ser una empresa independiente, una división, un área comercial, un conjunto de
usuarios (desligados de la empresa), etc.
El objetivo de un servicio SOA es el de dar una solución efectiva a una necesidad dentro del
ecosistema. Cualquier tecnología o infraestructura creada para soportar este servicio es parte del
ecosistema SOA.
Los actores SOA son aquellos que interactúan internamente con el sistema y participan en la
identificación de necesidades y nuevos requisitos, desde usuarios y TI hasta gobierno. Pero
además de los actores, cualquier “stakeholder” o interesado toma parte en la identificación de
necesidades y soluciones a través de su implicación como proveedor, contratista, mediador, socio,
cliente, etc. y por tanto, es parte también de la estructura social SOA. El diseño del ecosistema
potencia las relaciones entre clientes y proveedores, mejora la productividad de los empleados y
soporta eficientemente la toma de decisiones.
La visión del ecosistema SOA se puede centrar en una única organización empresarial o en una
malla con más de una organización o una pluralidad de individuos. Por ejemplo, imaginemos
cualquier asociación, empresa, corporación empresarial o agencia gubernamental. Cualquiera de
estas estructuras (u otros muchos ejemplos) interactúan con otras estructuras a través de
acuerdos, contratos, negociados o reglas de mercado para obtener un beneficio mutuo. Bajo la
misma perspectiva, un ecosistema SOA incluye esta diversidad de dominios que interactúan a
través de agentes software a cambio de un beneficio mutuo.
Por ejemplo, como expone Microsoft en una de sus publicaciones al respecto de SOA (11),
imaginemos una empresa cuya gestión de pedidos involucra a los departamentos de ventas,
almacén y logística. Vayamos más lejos y supongamos también que tanto el almacenaje como el
transporte de los pedidos están externalizados. Tenemos tres dominios internos implicados (los
departamentos) y tres dominios empresariales. Sumemos también que en la cadena de transporte
desde que un cliente realiza un pedido hasta que el producto llega a su destino contiene un alto
número de pasos manuales. El resultado final de este puzle puede estar muy lejos de las
expectativas más pesimistas en cuanto a eficiencia. En un escenario como este, construir un
ecosistema basado en la aceptación de contratos y la generación de servicios facilitará el flujo
automatizado de la información, sin retrasos, pérdidas o réplicas debidas al factor humano. Todas
las partes ganan ya que redunda en un beneficio mutuo.
Arquitectura SOA
Es evidente que cualquier ecosistema necesita la definición de responsabilidades, formas de

acuerdo, derechos y seguridad: fundamentos básicos de cualquier ecosistema SOA. Pero estos
fundamentos, también al igual que en el ejemplo de acuerdos empresariales, están condicionados
por la confianza y riesgo de cada acuerdo, y por tanto, no son iguales para todos. Por eso, las
reglas de contratos se pueden adaptar o deberían ser adaptables a cada situación y participante y
de forma evolutiva, con revisión de versiones, en función de la observación de evidencias que
aporten consistencia a dicha evolución.
A nivel estratégico, el ciclo de vida, o etapas en la implementación de un servicio, describe la

última fase o culmen de la planificación global de los servicios. Esta planificación se ve en la Figura
8 y comienza por la firma o aceptación del acuerdo de usuario (User Agreement) donde se
plantean los términos del contrato de provisión del nuevo servicio en cuanto a propósito, coste,
disponibilidad y certificaciones, entre otros. En la segunda fase, se especifican y acuerdan los
términos del servicio en cuanto a necesidades, funcionalidades, expectativas de prestación,
capacidad, políticas, convergencias tecnológicas y semánticas y calidad del servicio, entre otros.
La tercera fase se focaliza en la interfaz del servicio y su integración en cada dominio. Finalmente,
la cuarta fase desarrolla el ciclo de vida o etapas de implementación que ya hemos mencionado.
Acuerdo de usuario Servicio Interface Implementación
Descripción
Contrato
Mensajes Ciclo de vida
de la implantación del servicio
Figura 8. Fases en la planificación estratégica de servicios
3. Tecnologías de referencia
Como se dijo en la introducción, la arquitectura SOA es un paradigma o un estilo TI empresarial.

Por tanto, no podemos dar una tecnología o un protocolo que lo abarque plenamente. Al contrario,
SOA requiere del uso combinado de varios protocolos para cubrir las expectativas de las distintas
capas que hemos visto en la figura 6.
A continuación vamos a nombrar algunos de los protocolos y lenguajes más utilizados en la

implementación de arquitecturas SOA.
Sara Blanc Clavero
3.1. Creación de servicios
Podemos mencionar multitud de lenguajes que nos van a permitir crear nuestros servicios. Por
ejemplo, y entre muchos, JAX-WS es un conjunto de APIs que permite crear y utilizar servicios
web. Es compatible con SOAP (Simple Object Access Protocol), protocolo a nivel de mensajería
que veremos a continuación. También .Net soporta diferentes protocolos de comunicación pero
necesita combinarse con otros paquetes que permita interconectar servicios desarrollados en
diferentes plataformas. Por ejemplo, se utiliza WCF, compatible con los estándares WS- y SOAP.
3.2. Conectividad entre servicios
Protocolos de Servicios Web (WS-*): son un conjunto de protocolos que se podrían integrar en
varias de las capas SOA. Este conjunto de protocolos y estándares tienen una alineación muy
clara con SOA ya que sirven para intercambiar datos en Internet entre aplicaciones
independientemente (o transparente) al lenguaje de programación o plataforma sobre la que se
ejecuten. Podemos encontrar más información en W3C (16) y en OASIS (17). Por ejemplo, es uso
de contrato ya está establecido facilitando la descripción y descubrimiento del servicio. La intención
de registro de servicios de SOA se alinea con UDDI (Universal Description, Discovery and
Integration), con WS-Discovery y el formato WSDL (Web Services Description Language). WSDL
se combina con XML y a menudo con SOAP en la gestión de mensajería. No confundamos SOA
con SOAP. SOA es el término de referencia de la arquitectura mientras que SOAP es un protocolo
concreto de mensajería.
Mensajería SOAP: se describe en la ISO/IEC 40210 Information technology de 2011 (segunda

versión). Su éxito se basa en su potencial para sistemas descentralizados y distribuidos incluso
con restricciones de recursos. SOAP utiliza el formato XML creado por el W3C, que junto con otros
formatos como JSON (más ligero), se están convirtiendo en estándares de facto para conseguir la
interoperabilidad entre sistemas. En modelos B2B también se incluye EDI o MFT. Otros protocolos
que se absorben frecuentemente en SOA a nivel de comunicaciones son HTTP, JMS, FTP, VSAM,
CICS, Tuxedo y un largo etc. junto con protocolos WS-* para soportar direccionamiento y
seguridad, entre otros, ambos compatibles con el protocolo SOAP (WS-Addressing, WS-
ReliableMessaging).
Arquitectura REST: Conviene mencionar también la arquitectura REST. A diferencia de SOAP,

REST es un estilo de arquitectura, no un protocolo. Se puede implementar utilizando cualquier
protocolo que siga URI (Uniform Resource Identifier). REST puede alinearse con SOA ya que
también incluye el concepto de contrato cliente-servidor. Implementar REST, tal y como lo concibió
su autor (ver el blog y referencias de Roy T. Fielding) puede ser complejo para el inexperto y se
confunde a menudo con la implementación de interfaces (APIs) que utilicen HTTP. Sin embargo,
combinar REST sobre HTTP puede ser un todo un acierto ya que HTTP proporciona seguridad y
autenticación. La mensajería REST acepta cualquier formato (puede ser XML, JSON u otros), lo
que lo hace más apropiado que SOAP (aunque sacrificando ancho de banda) para trabajar con
componentes con restricciones de memoria o procesamiento tales como sensores.
Arquitectura SOA
3.3. Por encima de la capa de servicios
Orquestación y coreografía: Como ejemplos tenemos las implementaciones basadas en BPEL

(ej. WS-BPEL) para procesos orquestados y también encontramos referencias a herramientas
BPM (18), o específicas de Oracle (SCA), IBM, Microsoft y un largo etc.
Probablemente hay muchos más protocolos que se pueden integrar en una arquitectura SOA, pero
aquí lo dejamos como un ejercicio de investigación y “descubrimiento” para el alumno.
(1) Information technology -- Reference Architecture for Service Oriented Architecture (SOA RA) --
Part 1: Terminology and concepts for SOA.
Part 2: Reference Architecture for SOA Solutions.
Part 3: Service Oriented Architecture ontology.
(4) Service-Oriented Architecture: Concepts, Technology, and Design, Erl, T., (2014) 13ª edición.
Ed Prentice Hall professional technical reference.
(5) SOA Principles of Service Design, Erl, T., (2007) 1ª edición. Ed Prentice Hall.
(6) SOA Open Source, Davis, J., (2010). Ed Anaya multimedia.
(7) SOA Approach to Integration: XML, Web Services, ESB, and BPEL in real-world SOA projects,
Juric, M.B., Loganathan, R., Sarang, P., Jennings, F., (2007). Ed Packt Publishing
Birmingham-Mumbai.
(8) Introduction to Service Oriented Architecture (www.eu-orchestra.org) (2007).
(9) Service-oriented modeling and architecture. How to identify, specify and realize services for
your SOA, Arsanjani, A., (2004) IBM (ibm.com/redbooks).
(10) www.oracle.com/SOA
(11) La arquitectura Orientada a Servicios (SOA) de Microsoft aplicado al mundo real (2006)
Whilepapers Ed Microsoft.
Sara Blanc Clavero
(12) Technologies for SOA-based Distributed Large Scale Process Monitoring and Central
Systems, Jammes, F., Bony, B., Nappey, P., Colombo, A.W., Delsing, J., Eliasson, J.,
Kyvsakov, R., Karnovskos, S., Stluka, P. Tilly, M., (2012) IECON 38th Annual Conference
on IEEE Industrial Electronics Society Ed. IEEExplore pp. 5799-5804.
(13) Cloud Computing and SOA, Raines, G., (2009). Service-Oriented Architecture (SOA) Series,
Ed Systems Engineering at MITRE.
(14) 100 SOA Questions Asked and Answered, Holley, K., Arsanjani, A., (2001). Ed PEARSON,
custom edition for IBM.
(15) www.soaschool.com
(16) World Wide Web Consortium www.w3c.es
(17) OASIS www.oasis-open.org
(18) Application Platform for SOA and BPM. Reiem, T., (2007). Enterprise Technology Strategist,
SOA and BPM. Microsoft Corporation (EMEA).
Tema 26. Concepto, evolución y tendencias de los
sistemas operativos. Los sistemas UNIX y LINUX.
Los sistemas Microsoft Windows. Los sistemas
Android
Vicente Sancho Guijarro

Colegiado 0893
Los sistemas operativos son una parte esencial de cualquier sistema informático. Este
campo está cambiando muy rápidamente ya que las computadoras se encuentran en
multitud de contextos, aunque los conceptos fundamentales siguen siendo bastante
claros.
Este capítulo intenta definir el concepto de sistema operativo y su alcance, así como la
situación de los sistemas operativos hoy en día.
A continuación, se profundiza un poco más en los principales sistemas operativos:

Linux, Windows y Android. Para cada uno de ellos se empieza con una breve
contextualización, resumiendo su historia y de dónde vienen, para luego entrar en
algunos detalles de sus características. Estos sistemas operativos continúan
evolucionando con nuevas versiones, pero mantienen las bases sobre las que están
desarrollados.
1. Concepto, evolución y tendencias de los sistemas

operativos
1.1. Concepto
Un sistema operativo es un programa que se encarga de administrar el hardware (procesadores,

memoria principal, discos, pantalla y otros dispositivos de entrada/salida) de una computadora.
También proporciona las bases para los programas de aplicación ofreciendo un conjunto abstracto
de recursos simples y actúa como intermediario entre el usuario y la computadora, optimizando el
uso de estos componentes. Básicamente, ofrecen una forma razonable de resolver el problema de
crear un sistema informático utilizable, permitiendo ejecutar programas de usuario.
Sin embargo, no existe ninguna definición universalmente aceptada sobre qué forma parte de un
sistema operativo, ya que se puede encontrar una gran variedad de sistemas operativos en los
cuales varían enormemente sus características.
Teniendo esto en cuenta, otra definición común, es que un sistema operativo es aquel programa
que se ejecuta continuamente en la computadora, usualmente llamado kernel, siendo todo lo
demás programas del sistema y de aplicación.
La figura 1 representa el papel que juega el sistema operativo en el funcionamiento de la

computadora. Éste se sitúa entre la capa de hardware y la de aplicaciones del usuario. En la capa
inferior se encuentra el hardware (procesador, tarjetas, discos, teclado, ratón, pantalla, etc.), el
cual es controlado por el sistema operativo, ejecutándose en modo kernel o supervisor. En este
modo, se tiene acceso completo a todo el hardware, así como a todo el conjunto de instrucciones
que la máquina sea capaz de ejecutar.
Figura 1: Ubicación del sistema operativo
Concepto, evolución y tendencias de los sistemas operativos
Por el otro lado, el sistema operativo -el cual ya forma parte del software- se comunica con las
aplicaciones del sistema y con las del usuario, todo ello en modo usuario, con un conjunto de
instrucciones más limitado y que no comprometan al sistema operativo. Sin embargo, algunas
aplicaciones del sistema pueden tener privilegios para ejecutar algunas instrucciones del modo
kernel, como podría ser una aplicación para cambiar la contraseña del usuario. Es una operación
crítica y que requiere cierta protección, por lo tanto, está acción la llevará a cabo con una llamada
en modo kernel.
Esta distinción entre modo kernel o supervisor y modo usuario no es algo tajante ya que depende
del sistema operativo de dónde ponga la frontera. De hecho, suelen incluir muchas veces un shell
(consola con la que el usuario interactúa en modo texto) o GUI (Graphical User Interface: iconos,
ventanas, etc.), los cuales se ejecutan en modo usuario, al igual que las aplicaciones que el
usuario lanza desde ellos.
1.1.1. Tipos de sistemas operativos según su entorno
Desde los primeros sistemas operativos, han ido evolucionando y apareciendo distintos tipos de
sistemas operativos, según el propósito para el cual estuvieran destinados. A continuación, se
describen algunos de los principales tipos, aunque algunos sistemas operativos pueden pertenecer
a más de un tipo si se pueden desenvolver en varios escenarios con características distintas.
• Sistemas operativos de mainframe. Las computadoras mainframe son aquellas del tamaño
de una sala entera que aún se encuentran en los principales centros de datos corporativos.
Están profundamente orientados hacia el procesamiento de muchas tareas a la vez, las
cuales requieren muchas operaciones de E/S.
Ejemplos: OS/390 y algunas variantes de UNIX.
• Sistemas operativos de servidores. Se suelen ejecutar en computadoras potentes,

estaciones de trabajo o incluso en mainframes, los cuales dan servicio a varios usuarios a
la vez a través de una red y les permiten compartir recursos hardware y software. Algunos
de estos servicios podrían ser:
Servicio de impresión.
Servicios de ficheros.
Servicio web.
Etc.
Ejemplos: Solaris, FreeBSD, Linux, Windows Server 200x.
• Sistemas operativos de multiprocesadores. Están orientados a maximizar el poder de

cómputo conectando varias CPU en un solo sistema, por lo tanto, poseen características
especiales de comunicación, conectividad y consistencia.
Hoy en día, al ser muy común el uso de chips multinúcleo, la mayoría de sistemas
operativos ya lidia con estas características, aunque sea a menor escala que los sistemas
especializados.
Ejemplos: Linux, Windows.
• Sistemas operativos de computadoras personales. Su propósito es proporcionar un buen

soporte para un solo usuario de manera simultánea. Son los más populares, siendo
utilizados tanto en computadoras de sobremesa como en portátiles.
Ejemplos: Linux, FreeBSD, Windows XP/Vista/7/8/10, Mac.
• Sistemas operativos de computadoras de bolsillo. Se ejecutan sobre computadoras de

tamaño reducido como pueden ser PDA (Personal Digital Assistant), tabletas, teléfonos
móviles o smartphones. Son similares a las computadoras personales, radicando las
mayores diferencias en el peso, tamaño (y por tanto en la interfaz de usuario del sistema
operativo) y en los recursos de los que disponen (capacidad, velocidad de procesamiento,
batería). Además, cada vez disponen de más sensores (giroscopio, posicionamiento, etc.).
Ejemplos: Android, Windows Phone, iOS, Symbian.
• Sistemas operativos integrados. También son conocidos como incrustados o embebidos

(embedded), operan en los controladores de dispositivos que no se consideran
generalmente como computadores, ya que no aceptan software instalado por el usuario.
Esto significa la simplificación en la protección de las aplicaciones. Estos dispositivos
pueden ser microondas, televisores, automóviles, reproductores DVD y MP3.
Ejemplos: QNX, VxWorks, eCos.
• Sistemas operativos de nodos de sensores. Cada nodo de esta red es una pequeña
computadora que se comunica de forma inalámbrica con una estación base. Tienen
diversos usos como proteger perímetros de edificios, resguardar fronteras, detectar
incendios o realizar mediciones ambientales (temperatura, humedad, etc.). Deben ser
sistemas robustos para tolerar fallos en los nodos individuales y ser sencillo y simple dada
la poca RAM disponible y la importancia de la duración de las baterías de los nodos.
Ejemplos: TinyOS.
• Sistemas operativos en tiempo real. Estos sistemas se caracterizan por tener el tiempo
como parámetro clave. Se pueden clasificar en dos tipos.
En tiempo real duro. La acción debe ocurrir sin excepción en cierto momento o rango.
Se suelen encontrar en procesos industriales, aeronáutica o milicia.
En tiempo real suave. Se acepta que muy ocasionalmente se pueda fallar a un tiempo
determinado. Los sistemas multimedia están en esta categoría.
Ejemplos: QNX, RT-11, MarteOS, LynxOS.
1.1.2. Estructura de un sistema operativo
Como se ha visto, existe una gran variedad de sistemas operativos. Sin embargo, tienen muchas
características comunes como se va a ver a continuación.
Los sistemas operativos modernos están controlados mediante interrupciones. Si no hay ningún
proceso que ejecutar, ningún dispositivo de E/S al que dar servicio y ningún usuario al que
responder, el sistema operativo debe permanecer esperando a que algo ocurra. Esto reafirma la
definición anteriormente dada de que un sistema operativo es aquel programa que se ejecuta
continuamente en la computadora.
Los sucesos casi siempre se indican mediante la ocurrencia de una interrupción o una excepción.
Una excepción es una interrupción generada por software debida a un error o a una solicitud
específica de un programa de usuario de que se realice un servicio del sistema operativo. Es
necesario asegurar que un error que se produzca en un programa de usuario sólo genere
problemas en el programa que se esté ejecutando.
Para gestionar esto y poder distinguir entre la ejecución del código del sistema operativo y el
código definido por el usuario, el hardware suele proporcionar como mínimo dos modos de
ejecución:
• Modo usuario (bit de modo = 1).
• Modo kernel, también llamado modo de supervisor, modo del sistema o modo privilegiado
(bit de modo = 0).
A esta manera de ejecutar código se le llama modo dual de operación. El sistema operativo
arranca en modo kernel y los programas de usuario se ejecutan en modo usuario. Si un programa
de usuario solicita un servicio del sistema operativo, se pasa a modo kernel para satisfacer la
solicitud. Una vez finalizado el servicio, volverá a modo usuario. De este modo, las instrucciones
que pueden causar daño (instrucciones privilegiadas) sólo se ejecutan en modo kernel, lo que
añade protección.
Figura 2: Transición del modo usuario al modo kernel
Las llamadas al sistema proporcionan el medio para que un programa de usuario pida al sistema
operativo que realice tareas reservadas. Por otro lado, el uso del temporizador asegura que el
sistema operativo tenga el control sobre la CPU. Su duración suele ser variable y cada vez que el
reloj avanza el temporizador se decrementa. Cuando alcanza el valor 0, éste lanza una
interrupción. De esta manera se protege de que ningún programa de usuario se quede en un bucle
infinito o bien, nunca devuelva el control al sistema operativo.
1.1.2.1. Gestión de procesos
Un proceso es una unidad de trabajo en un sistema. Cada sistema consta de una colección de
procesos, siendo algunos del sistema operativo y el resto procesos de usuario. Un programa en
ejecución es un proceso. También es posible proporcionar llamadas al sistema que permitan a los
procesos crear subprocesos o hebras que se ejecuten de manera concurrente. Cada hebra tiene
un contador de programa que especifica la siguiente instrucción a ejecutar. Un proceso necesita
ciertos recursos como son tiempo de CPU, memoria, archivos y dispositivos de E/S.
El sistema operativo es responsable de las siguientes actividades en lo referido a la gestión de

procesos.
• Crear y borrar los procesos de usuario y de sistema.
• Suspender y reanudar procesos.
• Proporcionar mecanismos para la sincronización de procesos.
• Proporcionar mecanismos para la comunicación de procesos.
• Proporcionar mecanismos para el tratamiento de los interbloqueos.
1.1.2.2. Gestión de memoria
La memoria principal es un repositorio de datos rápidamente accesibles, compartida por la CPU y

los dispositivos E/S, la cual está formada por palabras o bytes, cada una con su propia dirección.
Es generalmente el único dispositivo de almacenamiento de gran tamaño al que la CPU puede
acceder directamente. Por lo tanto, para ejecutar un programa o procesar datos de un disco, esta
información debe transferirse a la memoria principal.
32 64
Si el sistema operativo es de 32 o 64 bit, tendrá un espacio de direcciones de 2 o 2 bytes
respectivamente. Este espacio de direcciones está desacoplado de la memoria física de la
computadora, pudiendo ser mayor o menor que esta. En caso de ser mayor, se utiliza la llamada
memoria virtual, que consiste en mover parte de las direcciones de memoria al disco.
El sistema operativo es responsable de las siguientes actividades sobre la gestión de la memoria.
• Controlar qué partes de la memoria están actualmente en uso y por parte de quién.
• Decidir qué datos y partes de procesos añadir o extraer de la memoria.
• Asignar y liberar la asignación de espacio de memoria según sea necesario.
1.1.2.3. Gestión de almacenamiento
El sistema operativo abstrae las propiedades físicas de los dispositivos de almacenamiento y

define una unidad de almacenamiento lógico, el archivo. Por lo tanto, implementa el abstracto
concepto de archivo gestionando los medios de almacenamiento y los dispositivos que lo
controlan. En esta gestión del almacenamiento, se incluyen dispositivos como los discos, así como
soportes físicos (CD, DVD, cintas, disquetes).
También debe gestionar el almacenamiento en caché. Esta técnica consiste en mantener una
copia de forma temporal de la información que se esté utilizando en un sistema de almacenamiento
más rápido. Con esto se crea una estructura jerárquica, de forma que lo que los mismos datos
pueden aparecer en los distintos niveles de la memoria. Así, un dato que este en uso, estará a la
vez en el disco, en la memoria principal, en la caché y en el registro hardware.
Figura 3: Migración de un dato A del disco al registro
Esto gana complejidad en entornos multiprocesador y en sistemas distribuidos, al tener varias

cachés distintas, donde un cambio debe reflejarse inmediatamente en el resto.
Algunas actividades de las cuales el sistema operativo es el responsable son las siguientes.
• Creación y borrado de archivos.
• Creación y borrado de directorios.
• Soporte de primitivas para manipular archivos y directorios.
• Asignación de archivos a los dispositivos de almacenamiento.
• Gestión del espacio libre.
• Asignación del espacio de almacenamiento.
• Planificación del disco.
• Montaje y desmontaje de medios en los dispositivos.
• Asignación y liberación de dispositivos.
1.1.2.4. Protección y seguridad
Si un sistema operativo permite la ejecución concurrente de varios procesos, el acceso a datos

debe regularse, asegurándose que sólo puedan utilizar los recursos aquellos procesos que hayan
obtenido la autorización del sistema operativo. Esta protección engloba cualquier mecanismo que
controle el acceso de procesos y usuarios a los recursos definidos por un sistema informático. Uno
de estos mecanismos sería la administración del sistema de archivos de manera que sólo sean
accesibles por los usuarios autorizados.
Por otro lado, es responsabilidad de los mecanismos de seguridad, defender el sistema frente a
ataques internos y externos. Estos ataques pueden ser virus y gusanos, ataques de denegación de
servicio, robos de identidad. La prevención de algunos ataques se considera una función del
sistema operativo en algunos sistemas, mientras que en otros se relega a algún software adicional.
1.1.3. Tipos de sistemas operativos según su estructura
Los sistemas operativos, entre otras cosas, se pueden clasificar según el diseño de su estructura.
Un sistema operativo no tiene por qué pertenecer inequívocamente a uno de estos grupos, también
puede tener características de varios grupos.
• Sistemas monolíticos. En este diseño, todo el sistema operativo se ejecuta como un solo
programa en modo kernel. Se escribe como una colección de procedimientos, enlazados
entre sí en un solo programa binario ejecutable extenso. Por lo tanto, estos procedimientos
se pueden llamar entre sí sin restricción y suele producir un sistema poco manejable y
difícil de comprender.
Además del núcleo que se carga al arrancar la computadora, suelen soportar extensiones
como lo son los drivers de los dispositivos de E/S, los cuales se cargan por demanda.
• Sistemas de capas. Son sistemas operativos organizados como una jerarquía de capas,
cada una construida sobre la que tiene debajo. Así, los diseñadores pueden elegir dónde
dibujar la línea entre el kernel y el usuario. Un ejemplo de esta estructura fue el sistema
THE, construido por E. W. Dijkstra.
Tabla I: Estructura del sistema operativo THE
Capa Función
5 El operador
4 Programas de usuario
3 Administración de la entrada/salida
2 Comunicación operador-proceso
1 Administración de memoria y tambor
0 Asignación del procesador y multiprogramación
• Microkernels. La idea básica es dividir el sistema operativo en módulos pequeños y bien

definidos. Sólo uno de estos módulos se ejecuta en modo kernel (microkernel) y el resto se
ejecuta como procesos de usuarios ordinarios. De esta forma, un error en uno de los
módulos puede hacer que falle ese módulo, pero no el sistema entero.
• Modelo cliente-servidor. Se trata de una modificación de la estructura de microkernel, pero

diferenciando dos tipos de procesos: los servidores, cada uno de los cuales proporciona un
servicio, y los clientes, que utilizan estos servicios. La comunicación entre ellos se realiza a
través de mensajes. Este modelo se puede utilizar para un solo equipo o para una red de
equipos.
• Máquinas virtuales. Surgieron de la necesidad de muchos usuarios del OS/360 de poder

trabajar de manera interactiva en varias terminales sobre un mismo hardware. Durante
varias décadas se basó únicamente en eso, pero en los últimos años se han utilizado para
cubrir nuevas necesidades. Mediante la virtualización, muchas compañías pueden ejecutar
en una misma máquina los servidores de correo, web y FTP, sin que un fallo en un servidor
afecte al resto. También se ha hecho muy popular en el hospedaje web compartido. Otro
uso es la posibilidad de ejecutar dos o más sistemas operativos al mismo tiempo, en la
misma máquina.
1.2. Evolución y tendencias
La evolución de los sistemas operativos siempre ha ido ligada a los avances tecnológicos en la
arquitectura del computador, los sistemas de comunicaciones y a los sistemas de almacenamiento
de la información. Con el paso de los años, los sistemas operativos se han tenido que ir adaptando
a estos cambios aumentando sus responsabilidades y mejorando las que ya tenía.
Tabla II: Nuevas funciones de los sistemas operativos de lo largo del tiempo
Década Funciones del SO Tipo de SO

1950 Secuencia automática de trabajos
Sistemas por lotes simples
Procesamiento por lotes
(batch processing)
Acceso a dispositivos E/S
1960 Planificación de trabajos
y multiprogramación
Sistemas por lotes multiprogramados
Gestión y protección de memoria
Gestión de disco
1970 Interacción usuario-máquina
Multiprogramación y
sincronización de procesos Sistemas de tiempo compartido
Gestión y protección de archivos
Gestión de máquina virtual
1980 Interfaz gráfica con ventanas y ratón (GUI)
Capacidad multimedia Sistemas para computadores personales
Acceso a red
1990 Multiprocesador y multinúcleo Sistemas paralelos
Tolerancia a fallos Sistemas de tiempo real
Comunicación entre nodos Sistemas distribuidos
Compartición de carga y recursos Computación en grid
2000 Almacenamiento y computación remota Nube
Trabajo con aplicaciones web Web OS
El siguiente gráfico muestra los porcentajes de utilización de los distintos sistemas operativos
desde el año 2008 hasta la actualidad.
Figura 4: Evolución de la cuota de mercado de los sistemas operativos
Se observa que la posición de los sistemas operativos de Microsoft (Windows) son los claros
dominantes. Sin embargo, hay una tendencia a la baja en su cuota de mercado debido al auge de
las plataformas móviles (teléfonos, tabletas) donde Microsoft no domina el mercado.
Los cambios de versiones de Windows se producen lentamente, probablemente porque los

usuarios suelen cambiar el sistema operativo cuando cambian de ordenador personal, cosa que
cada vez ocurre menos a menudo.
Atendiendo a las cifras, Windows XP -lanzado en 2001- fue el sistema operativo más utilizado
hasta mediados de 2012, cuando fue superado por Windows 7. Hoy en día camina hacia la
irrelevancia, más aún desde que el 8 de abril de 2014, Microsoft anunció el fin del soporte.
Sin embargo, su sucesor Windows Vista fue un fracaso comercial y nunca llegó a superar el 20%
de mercado. Con el que tuvo mucho más éxito fue con Windows 7, superando a Windows XP a
mediados de 2012 y llegando a obtener una cuota de casi el 50% tras el fin del soporte a Windows
XP.
Tras este llegó Windows 8 con un gran fracaso respecto a las expectativas.
Para terminar con los sistemas operativos de Microsoft, en julio de 2015 se lanzó Windows 10. Su
arranque fue fulgurante, en gran parte debido a la decisión de proporcionar la actualización gratuita
a todos los equipos que estén funcionando con Windows 7 o Windows 8. Tras esta actualización
masiva, el crecimiento se ha desacelerado.
El mayor crecimiento que se está produciendo hoy en día y que se prevé que seguirá en auge, es
el segmento de los sistemas operativos móviles (Android, iOS, etc.). Su uso es reciente, desde la
introducción de los llamados smartphones y las tabletas, pero está teniendo una tendencia a seguir
creciendo, aunque todavía se encuentran lejos del conjunto de sistemas operativos Windows.
Respecto a los sistemas operativos Mac de escritorio, han aumentado ligeramente su cuota de
mercado, pero siguen manteniéndose muy por debajo de Windows.
Y por último aparece un uso residual del 1% de sistemas operativos libres de escritorio (Linux,
BSD, etc.).
1.2.1. Sistemas operativos en dispositivos móviles
Con la proliferación de los llamados teléfonos inteligentes o smartphone y de las tabletas, han
emergido con fuerza los sistemas operativos destinados a estos dispositivos.
Tabla III: Momento en el que los smartphones superan a los móviles convencionales
País Mes
Reino Unido Mayo 2010
España Septiembre 2010
Alemania Enero 2011
Francia Febrero 2011
Italia, Canadá Junio 2011
Estados Unidos Julio 2011
A continuación, se presenta una tabla comparativa de los principales sistemas operativos móviles
con algunas de sus características.
Tabla IV: Comparativa de los principales sistemas operativos móviles
Windows
Apple iOS 8 Android 6.0 Blackberry 10 Firefox OS 2.2
Phone 8
Open Handset Mozilla
Compañía Apple Microsoft Blackberry
Alliance Foundation
Núcleo del SO Mac OS X Linux Windows NT QNX Linux
Licencia de
Propietaria Libre y abierto Propietaria Propietaria Libre y abierto
software
Año de
2007 2008 2010 1999 2013
lanzamiento
Webkit /
Motor web Webkit Trident Webkit Webkit
Chromium
ARM, MIPS,
CPU soportada ARM ARM ARM ARM, x86
x86
Soporte 64 bits Sí Sí No No No
Lenguaje de Objective-C, C#, Visual HTML5,
Java, C++ C, C++, Java
programación Swift, C++ Basic, C++ Javascript
Multiusuario No Sí No No No
En cuanto a la cuota de mercado dentro de este subconjunto de sistemas operativos, Android es el

claro vencedor y la tendencia es que continúe siéndolo. En segundo lugar, pero muy lejos, se
encuentra iOS. Este es utilizado en los dispositivos de Apple, a diferencia de Android que se utiliza
en multitud de fabricantes, lo que ayuda a su difusión.
El siguiente en discordia es Windows Phone, que se mantiene por debajo del 1%. Con el paso del
tiempo, han ido convirtiéndose en irrelevantes otros sistemas operativos como BlackBerry y
Symbian OS.
Figura 5: Cuota de mercado de los sistemas operativos móviles en todo el mundo (Fuente: Gartner
Group).
2. Los sistemas UNIX y LINUX.
Unix y Linux tienen una historia larga e interesante. Empezó como un proyecto del investigador
Ken Thompson hasta llegar a convertirse en una industria que involucra a universidades, empresas
multinacionales y gobiernos.
2.1. UNIX
2.1.1. Historia de Unix
La primera versión de UNIX fue desarrollada en 1969 por Ken Thompson del grupo de
investigación de los Bell Laboratories. Pronto se unió a él Dennis Ritchie, quien había trabajado en
el proyecto MULTICS, del cual se tomaron muchas características. En la tercera versión se
reescribió la mayor parte del sistema operativo en el lenguaje C, sustituyendo a ensamblador. Al
mismo tiempo se trasladó a sistemas más potentes y con soporte hardware para la
multiprogramación. Al tener más código en C era más fácilmente portable entre máquinas con
distinta arquitectura.
En 1974, Ritchie y Thompson publicaron un famoso artículo sobre UNIX, el cual estimuló a muchas
universidades para que pidieran a Bell Labs. una copia de UNIX, la cual era licenciada a estas por
una modesta cuota. La PDP-11 era la computadora preferida de la mayoría de los departamentos
de ciencias computacionales, pero sus sistemas operativos eran pésimos, por lo que UNIX llenó
este vacío con rapidez. Además, incluía el código fuente completo, por lo que se podía hacer
modificaciones sobre él.
En 1978, se distribuyó la versión 7, con 18800 líneas de código en C y 2100 en ensamblador. Tras
esto, el UNIX Support Group (USG) asumió el control de UNIX dentro de AT&T, la organización
matriz de Bell Laboratories ya que UNIX se estaba convirtiendo en un producto destacado y
necesitaba más atención que la que se le estaba prestando. La primera versión de USG fue
System III, en 1982, la cual incorporaba características de la versión 7 así como de varios sistemas
UNIX desarrollados por distintos grupos.
En 1983 se liberó System V. Justo después, el USG se reestructuró como el UNIX System
Development Laboratory (USDL). Dado el pequeño tamaño, la modularidad y el aseado diseño, se
iniciaron muchos trabajos basados en UNIX en multitud de organizaciones, siendo el más
influyente el de la University of California at Berkeley. En 1978, produjeron 3BSD UNIX, el cual
añadía memoria virtual, paginación por demanda y reemplazo de páginas entre otras cosas.
En la versión 4.2BSD UNIX, apoyándose en los protocolos de Internet de DARPA (TCP/IP), ya era
posible comunicarse entre instalaciones de red diversas, incluidas redes de área local y de área
extensa. Además, Berkeley adaptó muchas características de los sistemas operativos
contemporáneos para mejorar UNIX. Entre ellas una nueva interfaz con el usuario (C Shell), un
nuevo editor de textos (ex / vi) y muchos programas de sistemas nuevos.
En 1986 se liberó 4.3BSD. La última versión de Berkeley, la 4.4BSD, se terminó en junio de 1993.
Esta versión incluye soporte X.25 para trabajo con redes y cumplimiento del estándar POSIX.
El conjunto actual de sistemas operativos UNIX no está limitado a los producidos por Bell
Laboratories y Berkeley, sino que se han ido creando multitud de sistemas operativos UNIX y de
tipo UNIX. Por ejemplo, Microsoft reescribió UNIX para la familia 8088 y lo llamó XENIX, así como
su sistema operativo llamado Windows NT acusa una marcada influencia de UNIX.
2.1.2. Características de Unix
UNIX se diseñó como un sistema de tiempo compartido. La interfaz estándar con el usuario es
sencilla y puede ser sustituida por otra si se desea. El sistema de archivos es un árbol con
múltiples niveles que permite crear subdirectorios. Cada archivo de datos de usuario es tan solo
una secuencia de bytes. Los archivos de disco y los dispositivos E/S se tratan de la manera más
similar posible.
Un proceso puede crear fácilmente procesos nuevos. La planificación de la CPU es un sencillo

algoritmo de prioridades. 4.3BSD usa paginación por demanda como mecanismo para apoyar las
decisiones de gestión de memoria y planificación de la CPU.
La mayor parte de los algoritmos utilizados se escogieron primando la sencillez sobre la rapidez o
la sofisticación, con la intención de que otras personas pudieran construir un sistema más complejo
en caso de necesitarlo. No se estableció un diseño detallado antes de implementar UNIX, lo que le
dio una flexibilidad que ha sido clave en su desarrollo.
El sistema UNIX fue diseñado por programadores para programadores, por ello, siempre ha sido
interactivo y las funciones para desarrollar programas siempre han tenido prioridad. Está escrito
principalmente en C, simplificando mucho trasladar UNIX de unas máquinas a otras. Desde el
principio han estado todas las fuentes disponibles en línea, facilitando el descubrimiento de
deficiencias y su corrección. Esto ha fomentado la abundancia de variantes de UNIX que existen,
pero también cada vez que había un avance en la industria -trabajo con redes, ventanas, etc.-,
UNIX podía absorberlo sin dejar de ser UNIX.
La mayor parte de los programas se escriben en C y las llamadas al sistema se presentan como
funciones en C, por lo que los detalles de estas sólo las conoce el compilador, ahorrando en la
mayoría de ocasiones al programador el bajar a este nivel.
2.2. LINUX
Al igual que BSD, Linux es otro sistema operativo de tipo UNIX. Como Linux se diseñó para
ejecutar el mayor número posible de aplicaciones UNIX estándar, tiene mucho en común con las
implementaciones existentes de UNIX.
2.2.1. Historia de Linux
Su desarrollo se inició en 1991, cuando un estudiante finlandés, Linus Torvalds, escribió un

pequeño núcleo para el procesador 80386, el primero procesador de 32 bits de Intel. Desde sus
inicios, se ofrecía gratuitamente su código fuente por Internet, colaborando muchos usuarios de
todo el mundo casi exclusivamente a través de Internet.
En sus inicios, el desarrollo de Linux giraba alrededor del núcleo del sistema operativo: el ejecutivo
privilegiado que administra todos los recursos del sistema e interactúa directamente con el
hardware. Éste núcleo es totalmente original, desarrollado desde cero por la comunidad Linux.
El primer núcleo Linux fue liberado el 14 de mayo de 1991, etiquetada como la versión 0.01. Esta
versión no trabajaba con redes, sólo se ejecutaba en procesadores compatibles con el 80386 de
Intel y contaba con un soporte de drivers de dispositivos muy limitado. El único sistema de archivos
que se reconocía era el de Minix, ya que los primeros núcleos de Linux se desarrollaron de forma
cruzada con Minix.
El 14 de marzo de 1994 apareció la versión 1.0 de Linux. La novedad más importante fue el trabajo
con redes: incluía soporte de los protocolos de redes TCP/IP, así como una interfaz de sockets o
drivers de dispositivos para IP. También incluía un sistema de archivos nuevo muy mejorado y
reconocía controladores SCSI para acceso a disco de alto desempeño. El soporte de hardware
había crecido para incluir dispositivos de disco flexible, CD-ROM o tarjetas de sonidos. A nivel de
gestión de procesos, se incluyó un sistema de memoria compartida, semáforos y colas. Se
proporcionó un soporte sencillo para módulos del núcleo que se podían cargar y descargar
dinámicamente.
Como el desarrollo de nuevas versiones coincidía con la corrección de errores del núcleo actual,
se adoptó el siguiente patrón para la numeración de versiones: los núcleos con número de versión
menor impar (1.1, 1.3, 1.5, etc.) serán núcleos de desarrollo, mientras que los pares serán núcleos
estables, es decir, de producción.
En marzo de 1995 se liberó el núcleo 1.2, centrado en ampliar el soporte de hardware, así como
soporte a otros procesadores como Sparc, Alpha o MIPS.
La versión 2.0 de Linux, se liberó en junio de 1996, con dos nuevas capacidades importantes:
soporte de múltiples arquitecturas como al sistema Alpha de 64 bits y el soporte a arquitecturas
multiprocesador. Por otra parte, se mejoró sustancialmente la gestión de memoria para contar con
un caché unificado para datos del sistema de archivos independiente del uso de cachés con
dispositivos por bloques. Con esto mejoró el desempeño del sistema de archivos y de la memoria
virtual.
Otras mejoras de esta versión fue la mejora del desempeño de TCP/IP, la capacidad de montar
volúmenes de redes SMB o el soporte de hilos internos del núcleo o la carga automática de
módulos por demanda.
El 22 de julio de 2011 se lanzó la versión 3.0 del núcleo. El salto en la numeración fue más bien un
cambio estético -debería haber sido la versión 2.6.40 de haber continuado la serie- que un cambio
importante en las características. Aun así, entre las novedades más importantes se encuentran la
defragmentación automática, el soporte para XEN o el arranque por red.
La versión 4.0 de Linux vio la luz el 12 de abril de 2015. A parte de las típicas mejoras en cuanto a
un aumento de dispositivos compatibles y en la mejora de los drivers ya implementados y
corrección de errores, la principal novedad es la posibilidad de actualizar el kernel de Linux sin
necesidad de reiniciar el equipo.
Además del núcleo de Linux, el cual es el corazón del proyecto, otros componentes constituyen el
sistema operativo Linux completo. A diferencia del núcleo, una buena parte del software de soporte
que constituye el sistema Linux no es exclusivo de Linux, sino común a varios sistemas operativos
tipo UNIX. Utiliza muchas herramientas del sistema operativo BSD de Barkeley, el X Window
System de MIT y otras del proyecto GNU de la Free Software Foundation.
Este compartimento de herramientas ha funcionado en ambas direcciones. El sistema Linux global

es mantenido por una red informal de desarrolladores que colaboran por Internet.
2.2.2. Características de Linux
Linux es un sistema multiusuario, multitarea, con un conjunto de herramientas compatibles con

UNIX. Se asemeja a cualquier otra implementación tradicional de UNIX no basada en microkernel.
Se ejecuta en una amplia variedad de plataformas, aunque inicialmente se desarrolló para PC. Por
tanto, la velocidad y la eficiencia son metas importantes del diseño, pero también se han
concentrado los trabajos en la estandarización. Con la estandarización, se hace más fácil soportar
una amplia base de aplicaciones, lo cual es importante para un sistema operativo. Esto lo hace
soportando la norma POSIX básica y algunas extensiones.
Los estándares POSIX son un conjunto de especificaciones de diferentes aspectos del

comportamiento de un sistema operativo. Hay documentos POSIX para la funcionalidad común del
sistema operativo y para extensiones como hilos de procesos y operaciones en tiempo real.
El sistema Linux está formado por tres cuerpos principales de código:
• Kernel. Es responsable de mantener todas las abstracciones importantes del sistema

operativo, incluyendo elementos como la memoria virtual y los procesos. El kernel del
Linux forma la base del sistema operativo. Proporciona toda la funcionalidad necesaria
para ejecutar procesos y también proporciona servicios del sistema para que las
aplicaciones dispongan de acceso arbitrario y protegido a los recursos hardware.
• Bibliotecas del sistema. Definen un conjunto estándar de funciones mediante las que las
aplicaciones pueden interactuar con el kernel. Estas funciones implementan buena parte
de la funcionalidad del sistema operativo que no necesita los privilegios completos del
código del kernel. También pueden proporcionar versiones más complejas de las llamadas
al sistema básicas.
• Utilidades del sistema. Son programas que realizan tareas individuales y especializadas de
gestión. Aquí también se incluyen los demonios que son procesos ejecutados de manera
permanente, así como todos los programas necesarios para iniciar el sistema. Existen
utilidades para tareas cotidianas como puede ser listar el contenido de un directorio hasta
otras más complejas, como utilidades para procesamiento de textos.
El kernel tiene la capacidad de cargar y descargar secciones arbitrarias del código del kernel bajo
demanda. Estos módulos cargables se ejecutan en modo kernel privilegiado, así que disponen de
acceso completo a todas las capacidades hardware de la máquina donde se ejecutan. Como
cualquier persona puede modificar el kernel de Linux, de esta manera se ahorra el tener que
recompilar y rearrancar todo el núcleo, teniéndolo que hacer sólo para el módulo que esté
modificando.
Este soporte de módulos tiene tres componentes:
• Componente de gestión de módulos. Permite cargar módulos en memoria y que estos se

comuniquen con el resto del kernel. Además de cargar el contenido binario del módulo en
la memoria del kernel, también debe asegurarse de que todas las referencias que el
módulo realice a los puntos de entrada se actualicen para apuntar a las ubicaciones
correctas dentro del espacio de direcciones del kernel.
• Módulo de registros de controladores. Permite a los módulos informar al resto del kernel de
que hay un nuevo controlador. El kernel mantiene una serie de tablas dinámicas de todos
los controladores conocidos y proporciona un conjunto de rutinas para añadir o eliminar
controladores de estas tablas, las cuales incluyen controladores de dispositivos, sistemas
de archivo, protocolos de red y de formato binario.
• Mecanismo de resolución de conflictos. Permite a los diferentes controladores de

dispositivos reservar recursos hardware y proteger dichos recursos del uso accidental por
parte de otro controlador, de forma centralizada. Para ello, el kernel mantiene listas de los
recursos hardware asignados.
2.2.2.1. Gestión de procesos
Un proceso es el contexto básico en el que se da servicio a todas las actividades dentro del
sistema operativo. El principio básico consiste en separar dos operaciones: la creación de un
proceso (fork) y la ejecución de un nuevo programa (exec). Linux no distingue entre procesos e
hilos, sino que generalmente utiliza el término tarea.
Las propiedades de los procesos pueden clasificarse en los siguientes grupos:
• Identidad del proceso.
ID del proceso (PID). Es el identificador unívoco de cada proceso.
Credenciales. Cada proceso tiene un ID de usuario y un ID o más de grupo asociados

que determinan los derechos de un proceso para acceder a archivos y recursos del
sistema.
Personalidad. Cada proceso tiene asociado un identificador de personalidad que puede

modificar ligeramente la semántica de ciertas llamadas al sistema.
Espacio de nombres. Cada proceso está asociado a una vista específica de la

jerarquía del sistema de ficheros, también llamado namespace.
• Entorno del proceso. Se hereda del proceso padre y está compuesto por dos vectores:
Vector de argumentos. Enumera los argumentos de línea de comandos para invocar al

programa.
Vector de entorno. Es una lista de parejas nombre=valor que asocia una serie de
variables de entorno con nombre con sus correspondientes valores.
• Contexto del proceso. Se trata del estado del programa en ejecución en un momento
determinado, por lo que está variando constantemente. Incluye las siguientes partes:
Contexto de planificación. Contiene la información que necesita el planificador para

suspender y reiniciar el proceso. Incluye copias guardadas de todos los registros
procesos, así como información acerca de la prioridad y de las señales pendientes de
ser suministradas al proceso.
Contabilidad de recursos. Mantiene información acerca de los recursos consumidos por

cada proceso.
Tabla de archivos. Es una matriz de punteros a estructuras de archivos del kernel.
Contexto del sistema de archivos. Se aplica a las peticiones para abrir nuevos
archivos.
Tabla de rutina de tratamiento de señales. Define las rutinas que hay que invocar
cuando lleguen determinadas señales.
Contexto de memoria virtual. Describe el contenido completo del espacio de

direcciones privado del proceso.
2.2.2.2. Planificador de procesos
El planificador de Linux es un algoritmo apropiativo basado en prioridades. Tiene dos algoritmos

separados de planificación de procesos, por rango de prioridad: uno de tiempo compartido o nice
(de 100 a 140), donde el planificador planifica los procesos de forma justa, y el otro para tareas de
tiempo real (de 0 a 99), donde las prioridades absolutas es lo más importante, siendo los valores
inferiores las prioridades más altas.
Linux mantiene una lista de todas las tareas ejecutables en una estructura de datos denominada
cola de ejecución (runqueue), asignando a las tareas de mayor prioridad unos tiempos de
ejecución más largos.
La forma en que el kernel planifica sus propias operaciones es fundamentalmente distinta a la

forma en que planifica los procesos. El problema que se le plantea es que sus tareas pueden
intentar acceder a las mismas estructuras internas de datos, por lo que se requiere un marco de
trabajo que permita a las tareas del kernel ejecutarse sin violar la integridad de los datos
compartidos. Esto lo consigue con cerrojos de bucle sin fin (spinlock) y con semáforos. A partir de
la versión 2.6 del núcleo de Linux, el kernel ha pasado a ser apropiativo, es decir, una tarea puede
ser desalojada cuando se está ejecutando en el kernel, lo cual no se permitía en las versiones
anteriores.
2.2.2.3. Gestión de memoria
La gestión de memoria en Linux tiene dos componentes:
• Gestión de memoria física. Se encarga de la asignación y la liberación de la memoria

física: páginas, grupos de página y pequeños bloques de memoria. Linux separa la
memoria física en estas cuatro zonas o regiones:
ZONE_DMA. Son los primeros 16 MB de la memoria, que son los únicos a los que
pueden acceder algunos dispositivos ISA (Industry Standard Architecture).
ZONE_DMA32. Se corresponden con los primeros 4 GB de memoria, que son los

únicos a los que pueden acceder algunos dispositivos para dar soporte a las
direcciones de 64 bits.
ZONE_NORMAL. Identifica la memoria física que se mapea sobre el espacio de

direcciones de la CPU.
ZONE_HIGHMEM. Hace referencia a la memoria física que no está mapeada sobre el

espacio de direcciones del kernel. Por ejemplo, en la arquitectura de 32 bits de Intel (se
proporciona 232=4GB de espacio de direcciones), el kernel se mapea sobre los
primeros 896 MB del espacio de direcciones, por lo que el resto de la memoria es lo
que se denomina memoria alta.
Cada zona tiene su propio asignador de páginas y utilizan un sistema de descomposición

binaria para controlar las páginas físicas. Este sistema permita combinar o subdividir
regiones adyacentes de memoria para satisfacer las necesidades de las solicitudes de
memoria.
Para asignar memoria del kernel, Linux también emplea asignación de franjas. Una franja
se utiliza para asignar memoria para las estructuras de datos del kernel (descriptores de
procesos, objetos de archivos, semáforos, etc.) y está compuesta de una o más páginas
físicamente contiguas. Una franja tiene tres posibles estados: llena, vacía o parcial. Ante
una solicitud de un objeto libre, el asignador intentará ubicarlo en una franja parcial. Si no
hay ninguna, se ubicará en una franja vacía y de no haber, se creará una nueva franja.
• Gestión de memoria virtual. Gestiona la memoria mapeada sobre el espacio de direcciones

de los procesos que se está ejecutando. Crea las páginas bajo demanda y gestiona la
carga de dichas páginas desde el disco o la escritura de las mismas en el espacio de
intercambio del disco. En Linux, el gestor de memoria virtual mantiene dos vistas:
Vista lógica. El espacio de direcciones consta de un conjunto de regiones no

solapadas, donde cada región representa un subconjunto continuo del espacio de
direcciones con alineación de página. Las regiones están enlazadas en un árbol binario
equilibrado para permitir la búsqueda rápida.
Vista física. Está almacenada en las tablas de páginas hardware del proceso, las
entradas de la cual determinan la ubicación exacta de cada página de memoria virtual.
La política de descarga de páginas de Linux utiliza una versión modificada del algoritmo
estándar del reloj o de segunda oportunidad. Se utiliza un reloj con múltiples pasadas y en
cada pasada ajusta la edad de cada página usada, de manera que las menos usadas
tendrán valores más bajos. De esta manera, las páginas menos usadas son candidatas a
ser descargadas basándose en una política LFU (Least Frequently Used).
2.2.2.4. Sistema de archivos
Los archivos pueden ser cualquier cosa capaz de procesar la entrada o salida de un flujo de datos.
Por tanto, los controladores de dispositivos o las conexiones de red también pueden parecer
ficheros a ojos del usuario. El kernel de Linux gestiona todos estos tipos de archivos ocultando los
detalles de implementación por debajo de una capa de software, el VFS (Virtual File System).
El VFS está diseñado bajo los principios de la orientación a objetos. Hay definidos cuatro tipos de
objetos:
• Inodo. Representa un archivo individual. Es una estructura de datos que contiene punteros
a los bloques de disco donde están los propios contenidos del archivo. También contiene
información estándar acerca del archivo, como su propietario, su tamaño o el instante de
su última modificación. Cuando no está siendo utilizado, puede continuar en la caché del
VFS para mejorar la velocidad.
• Archivo. Representa un archivo abierto, definiendo un punto de acceso a los datos del
mismo. Por tanto, controla en qué lugar del archivo está leyendo o escribiendo actualmente
el proceso, con el fin de controlar las operaciones de E/S de archivo secuenciales.
Normalmente pertenecen a un único proceso. El tratamiento de los directorios es
ligeramente diferente a los archivos, ya que no requieren que el usuario abra los
correspondientes archivos a diferencia de lo que ocurre con la lectura o escritura de datos.
• Superbloque. Representa el sistema de archivos completo, como un conjunto conectado de

archivos. El kernel mantiene un único objeto superbloque por cada dispositivo de disco
montado como sistema de archivos y por cada sistema de archivos en red que esté
conectado. Principalmente se encarga de proporcionar acceso a los inodos.
• Entrada de directorio (dentry). Representa una entrada de directorio individual. Puede

incluir el nombre de un directorio o el propio archivo.
Para cada uno de estos cuatro tipos de objetos, VPS define un conjunto de operaciones, entre las
que se encuentran algunas como abrir, leer, escribir o mapear. Utilizando estas operaciones, VFS
no necesita conocer de antemano el tipo de objeto con el que está tratando.
El sistema de archivos ext3 / ext4
El sistema de archivos es heredado del desarrollo de Minix y tiene bastante en común con BDS
Fast File System (FFS). Cuando el sistema de archivos empleado en Minix se quedó obsoleto, se
desarrolló uno nuevo llamado Extended File System (extfs). Tras un rediseño, evolucionó a Second
Extended File System (ext2), en el cual se mejoró el rendimiento y la escalabilidad. Tras este, llegó
Third Extended File System (ext3) con más mejoras.
Los directorios son almacenados en el disco como archivos normales, aunque su contenido se
interpreta de distinta forma. Cada bloque en un directorio consiste en una lista enlazada de
entradas. El tamaño por defecto de un bloque en ext3 varía en función del tamaño total, pero
soporta bloques de 1, 2, 4 y 8 KB.
Cuando se localiza un archivo, primero ext3 debe seleccionar el grupo de bloque para ese fichero.
Para bloques de datos, se intenta situar el archivo en el grupo de bloque donde se encuentra el
inodo. Para los inodos, se intentan situar en el grupo de bloque donde reside el directorio padre.
Esta política está diseñada tanto para mantener la información relacionada en el mismo bloque de
grupo, como para reducir la fragmentación intentando mantener las localizaciones contiguas
físicamente.
El sistema de archivos ext3 implementa un diario, donde se escriben secuencialmente las

modificaciones del sistema de archivos. Un conjunto de operaciones llevadas a cabo por una tarea
recibe el nombre de transacción. Una vez escrita ésta en el diario, se considera que la transacción
está confirmada. Mientras tanto, las entradas del diario se van replicando al sistema de archivos y
una vez realizados los cambios, se eliminan del diario. Si el sistema sufre un fallo, algunas
transacciones pueden permanecer en el diario sin haberse replicado en el sistema de archivos.
Estas transacciones serían replicadas una vez el sistema se recupere, lo que dota al sistema de
archivos de consistencia.
Tras ext3, se desarrolló ext4. Este sistema de archivos, basado en el anterior y por lo tanto
compatible, añade nuevas características como el direccionamiento de 48 bits, posibilidad de
asignación de varios bloques en una sola llamada, fragmentación online o la ampliación de los
inodos con nuevos campos y atributos.
2.2.2.5. Seguridad
Autenticación
El objetivo principal es asegurarse de que nadie pueda acceder al sistema sin demostrar primero
que tiene los correspondientes derechos de entrada.
Tradicionalmente, la autenticación se realizaba utilizando un archivo de contraseñas. La

contraseña se combinaba con un valor aleatorio y el resultado se codificaba mediante una función
de transformación unidireccional y se almacenaba en dicho fichero.
Posteriormente, se desarrolló el sistema de módulos de autenticación conectables (PAM, pluggable

authentication modules), el cual está basado en una biblioteca compartida que puede ser utilizada
por cualquier componente del sistema que necesite autenticar a los usuarios. PAM permite cargar
módulos de autenticación bajo demanda, de forma que, si se añade un nuevo mecanismo de
autenticación, todos los componentes del sistema podrán aprovecharse de él inmediatamente.
Control de acceso
Trata de proporcionar un mecanismo para controlar si un usuario tiene derecho de acceso a un

cierto objeto e impedir el acceso a los objetos según sea necesario.
El control de acceso utilizando identificadores numéricos unívocos: de usuario (uid) y de grupo

(gid). Este mecanismo se aplica a diversos objetos del sistema, desde archivos hasta secciones de
memoria compartida o semáforos. Cada objeto tiene asociado un único uid y un único gid.
Linux realiza el control de acceso asignando a los objetos una máscara de protección que
especifica los modos de acceso (lectura, escritura o ejecución) que hay que conceder a los
procesos que tengan acceso de propietario, de grupo o resto del mundo. La única excepción es el
uid root privilegiado, el cual automáticamente tiene acceso a todos los objetos del sistema. Esta
máscara de protección tiene la siguiente estructura:
Trwxrwxrwx
La T del principio define el tipo del objeto y puede ser:
Tabla V: Tipo de objeto, definido en el primer carácter de la máscara de protección
Permiso Identifica
- Archivo
d Directorio
b Archivo de bloques especiales (Archivos especiales de dispositivo)
c Archivo de caracteres especiales (Dispositivo tty, impresora…)
l Archivo de vinculo o enlace (soft/symbolic link)
p Archivo especial de cauce (pipe o tubería)
El resto de letras se agrupan en conjuntos de 3, siendo el primero los permisos del usuario (uid), el
siguiente los permisos del grupo (gid) y el último los permisos del resto de usuarios (others). El
significado de cada letra es el siguiente:
Tabla VI: Significado de cada bit de permiso
Permiso Identifica
- Sin permiso
r Permiso de lectura
w Permiso de escritura
x Permiso de ejecución
Por ejemplo, de un archivo con la siguiente máscara: –rw-r-–r-–, se obtendría:
• Es un archivo (-).
• El usuario propietario puede leer y escribir, pero no ejecutar (rw-).
• El grupo propietario sólo puede leer (r--).
• El resto de usuarios sólo puede leer (r--).
2.2.3. Licencia de Linux
El núcleo de Linux se distribuye bajo la licencia GPL (General Public License) de GNU, cuyos
términos estableció la Free Software Foundation. Linux no es software de dominio público: los
derechos del código siguen siendo propiedad de sus diversos autores. Sin embargo, Linux es un
software gratuito en el sentido de que la gente puede copiarlo, modificarlo, usarlo y regalar sus
propias copias sin restricción alguna.
El software liberado bajo la licencia GPL no puede redistribuirse como producto exclusivamente
binario, sino que se debe al menos, dar la oportunidad de obtener el código fuente (aunque sea
pagando una cuota razonable).
2.2.4. Distribuciones de Linux
A medida que Linux ha ido madurando, diversos grupos han ido proporcionando un conjunto
estándar precompilado de paquetes fáciles de instalar, lo que facilita enormemente la instalación
de un sistema Linux. Estas colecciones o distribuciones incluyen mucho más que el sistema Linux
básico, incorporando paquetes listos para instalarse de muchas de las herramientas UNIX
comunes, como navegadores, servidores, procesadores de texto e incluso juegos. Muchas de
estas distribuciones suelen estar enfocadas a satisfacer las necesidades de un grupo específico de
usuarios, al ya incluir herramientas destinadas para ellos.
Algunas de las distribuciones más populares son las siguientes:
• Red Hat. Distribución comercial de Linux que ofrece una estabilidad y flexibilidad punteras,
lo que hace que sea una de las más recomendadas para empresas y servidores.
• Debian. Muy estable y 100% libre. Destaca su sistema de gestión de paquetes APT. Es
una de las distribuciones más importantes de GNU/Linux y más veteranas de las que aún
sigue en pie, ya que vio la luz en 1993.
• openSUSE. Está disponible con los entornos de escritorio KDE y Gnome, y cuenta con la
robusta herramienta de instalación y configuración Yast y el configurador gráfico SaX.
• Fedora. Distribución gratuita mantenida por la empresa Red Hat. Utiliza el sistema de
paquetería RPM (Red Hat Package Manager). Destaca por su seguridad gracias al sistema
SELinux (Security-Enhaced Linux).
• CentOS. Nació como un derivado gratuito de Red Hat en 2004, destinada al uso comercial.
• Arch Linux. Se trata de una distribución modular en la cual se empieza de cero, por lo que
no es recomendada para principiantes debido a su complejidad, pero a su vez lo hace un
sistema muy flexible. Utiliza Pacman, su propio gestor de paquetes.
• Ubuntu. Una de las distribuciones más utilizadas gracias a su facilidad de uso, ya que
cuenta con una interfaz muy intuitiva. Además, es compatible con la mayoría de hardware.
Está basada en Debian y ha sido creada por Canonical en 2004. Tiene detrás una
comunidad muy amplia, por lo que está en constante desarrollo y crecimiento.
• Mint. Está basada en Ubuntu y es de las más recomendadas para principiantes. Su entorno
de escritorio, Cinnamon, guarda muchas similitudes con Windows y es una bifurcación de
Gnome Shell.
• Lliurex, Molinux, Guadalinex, etc. Dada la adaptabilidad y la facilidad de crear

distribuciones con software ya preparado para su utilización que aporta Linux, algunas
administraciones públicas han creado sus propias distribuciones para fomentar el uso de
software libre. Por ejemplo, Lliurex es una distribución promovida por la Conselleria de
Educación de la Generalitat Valenciana, está basada en Ubuntu e incluye una colección de
herramientas libres para su uso en entornos educativos.
3. Los sistemas Microsoft Windows
El sistema operativo Microsoft Windows es un sistema operativo multitarea, cuyos objetivos clave
son la seguridad, fiabilidad, facilidad de uso, compatibilidad con aplicaciones Windows y POSIX,
altas prestaciones, ampliabilidad, portabilidad y el soporte internacional. Está destinado a equipos
de escritorio de consumidores y negocios, y a servidores empresariales.
3.1. Historia de Windows
A principios de la década de 1980, IBM estaba desarrollando una computadora personal basada en
el microprocesador 8088. Entonces IBM pidió una licencia del lenguaje de programación BASIC a
Microsoft, quien le sugirió que se pusiera en contacto con Digital Research para obtener una
licencia de su sistema operativo CP/M. Sin embargo, el presidente de Digital Research no pudo
reunirse con IBM, lo que hizo que volvieran con Microsoft. Poco después, Microsoft compró un clon
de CP/M a una empresa local, Seattle Computer Products, la portó a la IBM PC y le otorgó una
licencia a IBM. Este sistema operativo pasó a llamarse MS-DOS 1.0 (Disk Operating System) y se
incluyó en la primera IBM PC en 1981.
MS-DOS era un sistema operativo de línea de comandos, 16 bits, modo real y solo un usuario.
Durante esa década, MS-DOS fue evolucionando con la versión 2.0 (con soporte para la PC/XT, en
1983) y la versión 3.0 (con soporte para la PC/AX, en 1984).
Microsoft decidió proveer a MS-DOS con una interfaz gráfica de usuario, a la que denominó
Windows. Estuvo inspirando en los sistemas de investigación del Stanford Research Institute,
Xerox PARC y las computadoras Lisa y Macintosh de Apple. Las dos primeras versiones de
Windows (1985 y 1987) no tuvieron demasiado éxito.
En 1990, Microsoft liberó Windows 3.0 para Intel 386 y vendió más de un millón de copias en seis
meses. Sin embargo, Windows 3.0 no era un verdadero sistema operativo, sino un entorno gráfico
por encima de MS-DOS, el cual aún tenía el control de la máquina y del sistema de archivos.
En agosto de 1995 se liberó Windows 95, con muchas características de un sistema operativo
completo, como memoria virtual, administración de procesos y multiprogramación. Además,
introdujo las interfaces de programación de 32 bits. Le siguió Windows 98 (1998) y Windows Me
(2000), donde MS-DOS seguía ejecutando código ensamblador de 16 bits, lo que ocasionaba
problemas de estabilidad.
Paralelamente a todo esto, a mediados de 1980, IBM y Microsoft cooperaron en el desarrollo del
sistema operativo OS/2. En 1988, Microsoft decidió comenzar de nuevo y desarrollar un sistema
operativo portable, que se adaptara mejor a las nuevas tecnologías y a los nuevos componentes,
basado en una nueva tecnología (NT), que soportara la interfaz de programación de aplicaciones
(API) tanto de OS/2 como de POSIX.
La primera versión de Windows NT fue la 3.1, liberada en 1993. Se llamó 3.1 para corresponderse
con Windows 3.1 para el consumidor. También podría ejecutar programas Win32, pero mediante el
uso de la biblioteca de compatibilidad Win32s. No tuvo mucho éxito debido a la mayor complejidad,
mayores requerimientos e incompatibilidades con drivers de dispositivos y las aplicaciones, lo que
hizo que muchos usuarios se siguieran decantando por Windows basado en MS-DOS.
La primera actualización importante llegó con Windows NT 4.0, en 1996. Este sistema tenía la
potencia, seguridad y confiabilidad de NT, pero también tenía la misma interfaz de usuario que el
entonces muy popular Windows 95. Esto lo convirtió en un participante sólido en el mercado de las
computadoras de escritorio de alto rendimiento y en servidores.
Windows 2000 representó una evolución considerable para NT, incluyendo la tecnología plug-and-
play, servicios de directorio de red, administración de energía mejorada y una GUI mejorada.
Debido al éxito de este sistema operativo, Microsoft presionó con la liberación de Windows XP en
2001 para dejar de utilizar sistemas operativos basados en MS-DOS.
Windows XP fue un éxito, instalándose en cientos de millones de PCs, con su nueva interfaz
gráfica mucho más amigable. El sistema era demasiado complejo para producir versiones de
cliente y de servidor al mismo tiempo, por lo que dos años más tarde se liberó Windows Server
2003, que completaba el sistema operativo Windows XP con características para servidores.
En 2006, se liberó Windows Vista con otro diseño de interfaz gráfica y nuevas características de
seguridad. Le siguió su versión para servidores, Windows Server 2008. Los planes iniciales eran
tan ambiciosos que, dos años después de empezar su desarrollo, Vista se tuvo que reiniciar con un
menor alcance. Se tuvieron que posponer características como los planes de basarse en gran
parte en el lenguaje C# .NET con seguridad de tipos y recolección de basura, así como el sistema
de almacenamiento unificado WinFS.
El 22 de octubre de 2009, se liberó Windows 7. Solucionó la infinidad de incompatibilidades con

todo tipo de controladores que fueron uno de los mayores problemas de Vista. Es un sistema
robusto, rápido y estable. Se consiguió un arranque más rápido, un control de cuentas de usuario
menos molesto, ventanas multitouch y una mejor administración. Por todo esto fue un éxito de
ventas.
En 2012 se lanzó Windows 8, el cual fue pensado para poderse usar también en los nuevos
dispositivos (smartphones, tabletas). Por esta razón se optó por eliminar el menú inicio clásico.
Este cambio de interfaz, unido al buen funcionamiento de Windows 7, propició un recibimiento muy
flojo. Microsoft terminó lanzando Windows 8.1, una actualización grande, haciendo el sistema muy
estable y rápido, aunque no pudo remontar con el mal arranque de Windows 8.
En julio de 2015, Microsoft liberó Windows 10. Regresó el botón inicio, se dotó de un sistema de
tareas completamente renovado y se lanzó una tienda de aplicaciones, similar a la que ya tenían
Apple o Android.
3.2. Características de Windows
El modo de kernel en Windows está estructurado en el HAL, en los niveles del kernel y del
ejecutivo de NTOS (New Technology Operating System), y en un gran número de drivers de
dispositivos que implementan todo, desde los servicios de dispositivos hasta los sistemas de
archivos, las redes y los gráficos. EL HAL (Hardware Abstraction Level) es la capa que oculta
ciertas diferencias en el hardware de los demás componentes, exportando una interfaz virtual del
hardware usada por el resto de capas.
Figura 6: Organización de Windows en modo kernel.
El nivel del kernel está implementado en C, usando ensamblador sólo cuando es absolutamente
necesario. Tiene cuatro responsabilidades principales:
• Planificación de hilos de ejecución. Cada proceso tiene uno o más hilos, y cada hilo tiene
su propio estado, prioridad, afinidad de procesador y uso de la CPU. Los seis posibles
estados son: preparada, lista, en ejecución, en espera, en transición y terminada.
El planificador utiliza un esquema de 32 niveles de prioridad (a más nivel, más prioridad),

divididas en dos grupos: clase variable (de 1 a 15) y clase de tiempo real (de 16 a 31). Si
no se encuentra un hilo preparado, se ejecuta un hilo especial llamado hilo de inactividad
(idle thread) el cual tiene prioridad 0. Windows no es un sistema de tiempo real estricto, por
lo que no se garantiza que un hilo de tiempo real pueda comenzar a ejecutarse dentro de
un límite de tiempo.
• Implementación de primitivas de sincronización. Las estructuras de datos clave del sistema

operativo se gestionan como objetos, utilizando funciones comunes para la asignación,
para el recuento de referencias y para la seguridad. Los objetos del planificador controlan
la sincronización dentro del sistema. Algunos ejemplos de estos objetos son:
Eventos. Usados para registrar un evento ocurrido y para sincronizarlo con alguna
acción.
Mutantes. Suministra exclusión mutua del modo usuario y el modo kernel, asociado al
concepto de propiedad.
Mutex. Proporciona exclusión mutua antibloqueos en el modo kernel.
Semáforo. Controla el número de hilos que acceden a un recurso.
Hilo. Es la entidad que es planificada por el kernel. Está asociada al objeto proceso, el
cual encapsula su propio espacio virtual de direcciones.
Temporizador. Lleva el control del tiempo y envía un timeout cuando una operación
tarda demasiado y necesita ser interrumpida.
• Tratamiento de interrupciones y excepciones. Pueden ser producidas por software o por

hardware. Windows define diversas excepciones independientes de la arquitectura como
pueden ser: violación de acceso a memoria, desbordamiento de entero, división por cero,
instrucción ilegal, etc. Cada interrupción tiene una prioridad asociada y el servicio de las
interrupciones se realiza según el orden de prioridad. Windows tiene 32 niveles de solicitud
de interrupción (IRQ, interrupt request level).
Tabla VII: Niveles de peticiones de interrupción de Windows
Nivel Tipo de interrupción

31 Error de bus o de comprobación de máquina
30 Fallo de energía
29 Notificación interprocesador (petición de actuación a otro procesador)
28 Reloj
27 Perfil
3 – 26 PC IRQ – Interrupciones hardware tradicionales
2 Deferred Procedure Call (DPC)
1 Asynchronous Procedure Call (APC)
0 Asignación del procesador y multiprogramación
• Conmutar entre el modo usuario y el modo kernel. Cada hilo realmente puede dividirse en
dos: hilo de modo usuario e hilo de modo kernel. Cuando un hilo de usuario requiere un
cambio a modo kernel, el kernel se encarga de ello, devolviendo luego la ejecución al
modo usuario.
El sistema ejecutivo (executive) proporciona un conjunto de servicios utilizado por todos los
subsistemas de entorno. Estos servicios se pueden agrupar de la siguiente manera:
• Gestor de Objetos. Para gestionar las entidades de modo kernel, Windows utiliza un
conjunto genérico de interfaces que son manipuladas por los programas de modo usuario,
llamadas objetos. El sistema ejecutivo permite proporcionar un nombre interno a cada
objeto, los cuales se manipulan mediante un conjunto de funciones virtuales como create(),
open(), close() o delete() entre otras. El gestor de objetos es la única entidad que genera
descriptores de objetos. Un descriptor es un identificador unívoco para un proceso y que
confiere a este la capacidad de acceder y manipular un recurso del sistema.
Cada objeto está protegido mediante una lista de control de acceso que contiene los ID de
seguridad y los derechos de acceso concedidos. Generalmente, el creador del objeto
determina la lista de control de acceso al mismo.
• Gestor de memoria virtual. Gestiona el espacio virtual de direcciones, la asignación de

memoria física y la paginación. Windows utiliza un esquema de gestión basado en página
con un tamaño de página de 4KB en procesadores compatibles con IA32 y de 8KB en
máquinas IA64.
En los procesadores IA32, cada proceso tiene un espacio virtual de direcciones de 4GB,
siendo los dos primeros fundamentalmente idénticos en todos los procesos ya que son
utilizados en modo kernel para acceder al código y a las estructuras de datos del sistema y
los dos últimos específicos de cada proceso, tanto en modo kernel como en modo usuario.
Windows implementa la memoria compartida definiendo un objeto sección. Después de

obtener un descriptor de un objeto sección, los procesos mapean la parte de memoria que
necesitan dentro de su espacio de direcciones. La protección de las páginas componentes
de la sección puede configurarse como de sólo lectura, de lectura-escritura, de lectura-
escritura-ejecución, de sólo ejecución, sin acceso o de copia durante la escritura.
Una página física puede encontrarse en uno de los siete posibles estados: válida, libre,
borrada, modificada, reserva, corrupta o en transición.
Windows usa una política de reemplazo LRU (Least Recently Used) para las páginas de los
procesos, donde se reemplazan las que estadísticamente tienen menos probabilidad de ser
usadas nuevamente.
• Gestor de procesos. Proporciona servicios para crear, borrar y utilizar procesos, hilos y
trabajos. No tiene ningún conocimiento de las relaciones padre-hijo ni de las jerarquías de
los procesos. No está implicado en la planificación, ya que de esto se encarga el
planificador del kernel, pero sí que configura las prioridades y afinidades de los procesos.
Los propios procesos pueden agruparse en objetos trabajo.
El gestor de procesos también implementa la entrega y puesta en cola de llamadas a

procedimiento asíncrona (APC) a los hilos, las cuales son utilizadas para iniciar la
ejecución de hilos, completar la E/S, terminar los hilos y procesos y para asociar
depuradores.
• Funcionalidad de llamada a procedimientos locales. Utiliza un modelo cliente-servidor.

Muchas características como la gestión de la seguridad, de la impresión, las funciones
plug-and-play utilizan este modelo. Para reducir el consumo de memoria se suelen agrupar
dentro de unos cuantos procesos en el programa scvhost.exe.
La implementación normal de este paradigma es la de utilizar RPC para las peticiones.

Para el transporte de las llamadas del cliente al servidor se utiliza ALPC (Advance Local
Procedure Call Facility). Sin embargo, en las etapas tempranas del arranque RPC no está
disponible, por lo que los servicios nativos de Windows utilizan ALPC directamente.
• Gestor de E/S. Es el responsable de los sistemas de archivos, controladores de

dispositivos y controladores de red, gestionando también los buffers para las solicitudes de
E/S. Es fundamentalmente asíncrono.
Los controladores de dispositivos de Windows se escriben de acuerdo a la especificación

WDM (Windows Driver Model). Para facilitar el desarrollar controladores con este modelo,
existen los controladores de puerto. Dentro de una clase de dispositivos similares
(controladores de audio, SCSI, etc.), cada instancia de un dispositivo comparte un
controlador común de la clase denominado controlador de puerto. Este controlador
implementa las operaciones estándar para la clase y luego invoca las rutinas específicas
del dispositivo dentro del controlador de minipuerto de éste.
• Gestor de caché. Coopera estrechamente con el gestor de memoria virtual con el fin de
proporcionar servicios de caché para todos los componentes que están bajo el control del
gestor de E/S. El almacenamiento en caché en Windows está basado en archivos. Está
dividida en bloques de 256 KB, cada uno de los cuales puede almacenar una vista de un
archivo. Para cada archivo abierto, el gestor de caché mantiene una matriz índice VACB
independiente que describe el almacenamiento en caché para el archivo completo.
• Monitor de referencia de seguridad. La centralización de la gestión de las entidades del

sistema en el gestor de objetos permite a Windows utilizar un mecanismo uniforme para
llevar a cabo las validaciones de acceso en tiempo de ejecución y las comprobaciones de
auditoría para todas las entidades del sistema. Cada vez que un proceso abre un
descriptor de un objeto, el monitor de referencia de seguridad (SRM, Security Reference
Monitor) comprueba el testigo de seguridad del proceso y la lista de control de acceso del
objeto para ver si el proceso tiene los derechos necesarios.
• Gestor plug-and-play. El sistema operativo utiliza el gestor plug-and-play (PnP) para

reconocer los cambios en la configuración hardware y adaptarse a los mismos, mientras el
sistema sigue funcionando. El gestor también controla los recursos utilizados por cada
dispositivo y se responsabiliza de cargar los controladores apropiados. Como algunos
programas del sistema se interesan por la adición o la desconexión de dispositivos, el
gestor PnP soporta notificaciones.
• Gestor de energía. Windows soporta estrategias sofisticadas de eficiencia energética. El

gestor de energía detecta las condiciones del sistema actuales, como la carga de la CPU y
de los dispositivos de E/S, y mejora la eficiencia energética reduciendo el rendimiento del
sistema cuando las necesidades son bajas. Incluso puede copiar todo el contenido de la
memoria en el disco y apagar el sistema, a lo cual le llama hibernar, permitiendo el poder
volver a arrancar en muy poco tiempo. Al igual que el gestor PnP, también soporta
notificaciones, ya que a algunas aplicaciones les interesa conocer cuándo se va a apagar
el sistema para poder guardar sus estados antes de que esto se produzca.
• Registro. Windows mantiene buena parte de su configuración en unas bases de datos

internas, llamadas colmenas (hives), pero comúnmente llamado Registro. Existen distintas
colmenas para la información del sistema, las preferencias del usuario, la instalación de
software y para la seguridad. Se implementa como un componente del ejecutor porque
contiene información necesaria para el arranque del sistema.
El registro de Windows representa la configuración de cada colmena como espacio de

nombres de claves jerárquico (directorios), cada uno de los cuales puede contener un
conjunto de valores de distintos tipos: cadena UNICODE, cadena ANSI, entero o datos
binarios sin tipo.
Cuando se produce una actualización importante del sistema, como instalación de drivers o
actualizaciones del sistema, Windows crea un punto de recuperación del sistema antes de
hacer dichos cambios. Para incrementar la estabilidad del registro, Windows añade un
mecanismo de transacciones llamado KTM (Kernel Transaction Manager), el cual puede
ser usado para prevenir actualizaciones parciales del registro.
• Arranque. El arranque de un equipo con Windows comienza cuando se enciende el

hardware y comienza la ejecución del firmware de la ROM. En equipos antiguos era
llamado BIOS, pero los sistemas modernos utilizan UEFI (Unified Extensible Firmware
Interface). Tras esto, el firmware localiza el disco del sistema, carga el programa bootmgr y
comienza la ejecución del mismo para arrancar el sistema operativo. Si el sistema estaba
hibernando, carga el programa winresume, mientras que, si estaba completamente
apagado, bootmgr lleva a cabo la inicialización del sistema y entonces carga el programa
winload, el cual carga hal.dll, el kernel (ntoskrnl.exe), los drivers necesarios y el sistema de
colmenas. Una vez terminado todo el proceso, transfiere la ejecución al kernel.
El kernel se inicializa y crea dos procesos:
Proceso del sistema, contiene todos los hilos internos del kernel y nunca se ejecuta en
modo usuario.
Proceso en modo usuario, llamado SMSS (Session Manager SubSystem), el cual lleva
a cabo la inicialización del sistema, incluyendo los ficheros de paginación, carga de
drivers y la gestión de usuarios de Windows.
3.2.1. Sistema de archivos NTFS
El sistema nativo de archivos en Windows es NTFS y se usa en todos los discos locales. Algunos
dispositivos externos (lápiz USB, disco externo, tarjeta de memoria, etc.) pueden seguir usando
FAT32, pero una de sus desventajas es que no es capaz de restringir el acceso a los archivos por
parte de los usuarios autorizados. En cambio, NTFS utiliza ACLs (Access Control List) para
controlar el acceso a archivos individuales y soporta encriptación mediante BitLocker.
La entidad fundamental de NTFS es el volumen y está basado en una partición lógica de disco. No
trata con los sectores individuales del disco, sino que utiliza clústeres como unidades de
asignación de disco, el tamaño de los cuales es siempre una potencia de 2 y se selecciona al
formatear el disco. NTFS utiliza LCNs (Logical Cluster Numbers) como direcciones de disco,
numerando los clústeres desde el principio hasta el final del disco.
Un archivo en NTFS no es un simple flujo de bytes como en UNIX, sino que es un objeto
estructurado en atributos tipados. Todos los archivos en NTFS se describen mediante uno o más
registros dentro de una matriz almacenada en un archivo especial denominado MFT (Master File
Table). Cada archivo tiene un ID unívoco denominado referencia de archivo, el cual es un valor de
64 bits.
El espacio de nombres de NTFS está organizado como una jerarquía de directorios. Cada
directorio utiliza una estructura de datos denominada árbol B+ para almacenar un índice de los
nombres de archivo contenidos en ese directorio. Este árbol elimina el coste de reorganizar el
árbol.
Además del archivo MFT, se crea otro archivo con una copia de las 16 primeras entradas de la
tabla del mismo, que se utilizará para recuperar la MFT si ésta resulta dañada. Los siguientes
archivos que se crean también son de propósito especial e incluyen el archivo de registro, el
archivo de volumen, la tabla de definición de atributos, el directorio raíz, el archivo de mapa de bits,
el archivo de arranque y el archivo de clústeres erróneos.
3.2.2. Active Directory
El directorio activo o Active Directory, es la implementación de Windows de los servicios LDAP

(Lightweight Directory Access Protocol). Almacena la información acerca del dominio, gestiona las
cuentas de los usuarios y los grupos de usuarios del dominio, así como sus contraseñas, y
proporciona los soportes que necesita, como las Políticas de Grupo de Windows. Los
administradores emplean estas políticas para establecer estándares relativos a las preferencias y
al software de las máquinas a las que acceden los usuarios.
4. Los sistemas Android
El sistema operativo Android está diseñado para teléfonos móviles y, más recientemente, para
tabletas. Está basado en el kernel de Linux, pero combina código abierto (AOSP, Android Open
Source Project) con aplicaciones de terceros con código cerrado.
Google implementó Android para dar soporte a una amplia variedad de servicios propios en la
nube (Gmail, sincronización de calendario y contactos, mensajería nube-dispositivo, etc.). Google
Play es la tienda online de Google para las aplicaciones de Android.
Las distintas versiones se suelen identificar comercialmente con nombres de postres, por orden
alfabético. Las dos primeras versiones no obtuvieron este identificativo, pero desde la tercera
versión (1.5), se comenzó por la letra C con Cupcake.
4.1. Historia de Android
Android Inc. era una empresa fundada para desarrollar el software de teléfonos con más
funcionalidades que los que había por aquel entonces, lo que pasarían a llamarse teléfonos
inteligentes o smartphones. Se lanzaron varios prototipos para demostrar las ideas que tenían.
En julio de 2005, Google adquirió Android y lo provisionó de los recursos necesarios para continuar
el desarrollo como un producto completo. A principios de 2006, se decidió focalizar la plataforma
en Java, que hasta el momento también incluía otros lenguajes como C++ o JavaScript.
La primera versión del sistema operativo fue lanzada en noviembre de 2007. Sólo consistía en un
emulador hardware ejecutando el sistema Android con sus aplicaciones del núcleo, documentación
de la API y un entorno de desarrollo. A partir de aquí, se fue mejorando el sistema hasta que en
agosto de 2008 se alcanzó una versión estable y se integró en el T-Mobile G1 lo que sería Android
1.0.
Tras su lanzamiento, en febrero de 2009, apareció la versión 1.1. No se añadieron apenas

funcionalidades, sino que se corrigieron errores de la versión anterior.
En abril de 2009 vio la luz la versión 1.5 (Cup cake). Se incorporó el teclado en pantalla con
predicción de texto y los widgets de escritorio. Se añadió el soporte para Bluetooth estéreo.
En septiembre de 2009 salió la versión 1.6 (Donut), facilitando la adaptación de una aplicación a
las distintas densidades de las pantallas. Se añadió la capacidad para comandos por gestos
(gestures), la síntesis de voz y la búsqueda avanzada en todo el dispositivo.
Al mes siguiente, salió la versión 2.0 (Eclair), la cual tenía como principales novedades un sistema
centralizado de manejo de cuentas, soporte para HTML5, mayor velocidad de hardware y soporte
para pantallas multitáctil. En enero de 2010, se lanzó la versión 2.1, con la cual compartió su
nombre comercial al llevar pocas novedades, como el reconocimiento de voz.
La versión 2.2 (Froyo), lanzada en mayo de 2010, supuso una gran mejora en la velocidad de
ejecución de código debido a una nueva versión del compilador JIT de la máquina Dalvik. Se
mejoró el navegador web con soporte para Adobe Flash 10.1 y JavaScript V8. Se introdujo la
posibilidad de compartir la conexión a Internet con otros dispositivos (tethering) y el soporte a las
notificaciones push.
En diciembre de 2010 apareció la versión 2.3 (Gingerbread), con soporte para varias cámaras,
NFC, soporte para giroscopio y barómetro, mejoras en la máquina virtual Dalvik con un nuevo
recolector de basura y se cambió el sistema de archivos de YAFFS a ext4.
Para mejorar la experiencia con tabletas, en febrero de 2011 se lanzó versión 3.0, con un rediseño
de la interfaz, introduciendo la posibilidad de sustituir los botones físicos por botones en la pantalla.
Ese mismo año aparecieron las versiones 3.1 y 3.2, con mejoras menores, por lo que a todas las
versiones 3.x se les llamó Honeycomb.
La siguiente versión fue la 4.0 (Ice Cream Sandwich), lanzada en octubre de 2011, que
básicamente aunaba las características de las versiones anteriores (2.x para móviles y 3.x para
tabletas), en una sola versión compatible con cualquier dispositivo.
La versión 4.1 (Jelly Bean) fue lanzada en julio de 2012, la cual hizo hincapié en mejorar la fluidez
de la interfaz de usuario. También apareció por primera vez el asistente Google Now.
En octubre de 2013, se liberó la versión 4.4 (KitKat), donde se recortaron componentes para hacer
funcionar Android también en dispositivos con un hardware más limitado. Se introdujo la máquina
virtual ART, destinada a sustituir Dalvik, mejorando notablemente los tiempos de ejecución.
En noviembre de 2014, llegó la versión 5.0 (Lollipop), con la sustitución definitiva de ART por
Dalvik y la extensión de Android a otras plataformas (Android Wear -relojes-, Android TV -
televisores- y Android Auto -vehículos-).
Android 6.0 (Mashmallow) fue la siguiente versión, en octubre de 2015. La principal novedad fue la
introducción del administrador de permisos, de forma que el usuario puede gestionar cada permiso
de forma individual en cada aplicación.
4.2. Características de Android
4.2.1. Principios de diseño de Android
• Proveer de una plataforma completa de código abierto para dispositivos móviles.
• Fuerte soporte a aplicaciones de terceros, mediante una API robusta y estable,

proporcionado en un SDK (Software Development Kit) bien definido.
• Permitir a todas las aplicaciones de terceros competir entre sí, así como con las propias
aplicaciones de Google. Android debe permanecer neutral en esta competencia.
• Proveer de un modelo de seguridad de aplicaciones.
• Dar soporte a las interacciones típicas de los usuarios con el dispositivo móvil, las cuales
se suelen caracterizar por gastar cortos espacios de tiempo en varias aplicaciones.
• Gestionar los procesos del usuario, simplificando la experiencia (p.e. el usuario no debe
preocuparse de cerrar las aplicaciones) y gestionando eficientemente la memoria.
• Facilitar la colaboración entre las diferentes aplicaciones.
• Crear un sistema operativo completo de propósito general, no limitarse a ser una versión
reducida de los sistemas operativos de escritorio, lo que también facilitará el crecimiento
del mismo.
4.2.2. Arquitectura de Android
Internamente, Android está formado por cuatro capas: núcleo de Linux, Runtime de Android, las
librerías nativas y el entorno de aplicación.
Figura 7: Arquitectura de Android
• El núcleo de Linux. Android está construido sobre el núcleo Linux estándar, con algunas
extensiones. Proporciona servicios como la seguridad, el manejo de la memoria, el
multiproceso, la pila de protocolos y el soporte de drivers para dispositivos. Es la única
capa dependiente del hardware, ya que actúa como capa de abstracción entre el hardware
y el resto de la pila.
El primer proceso de usuario es init, el cual es la raíz de todos los demás. El proceso init
inicia una serie de demonios a bajo nivel, como es el gestor de archivos o el acceso al
hardware. Uno de estos procesos es zygote, el cual es el proceso raíz de todos los
procesos a alto-nivel programados con Java.
• Runtime de Android. Está basado en el concepto de máquina virtual utilizado en Java. Pero
Google decidió crear una máquina virtual nueva (Dalvik) que se adaptara mejor a las
limitaciones de los dispositivos móviles (poca memoria, procesador limitado). Los ficheros
ejecutables en Dalvik llevan la extensión .dex y cada aplicación se ejecuta en su propio
proceso Linux, con su propia instancia de la máquina virtual. A partir de la versión Android
5.0 se reemplazó Dalvik por ART, la cual consigue reducir el tiempo de ejecución de código
hasta en un 33%.
También se incluye en el runtime de Android el módulo Core Libraries, el cual contiene la

mayoría de las librerías disponibles en Java.
• Librerías Nativas. Incluye un conjunto de librerías en C/C++ usadas en varios componentes

de Android, las cuales están compiladas en código nativo del procesador. Muchas de las
librerías utilizan proyectos de código abierto. Algunas de estas librerías son:
System C library: una derivación de la librería BSD de C estándar (libc), adaptada para
dispositivos embebidos basados en Linux.
Media Framework: librería basada en OpenCORE de PacketVideo. Soporta codecs de

reproducción y grabación de multitud de formatos de audio y vídeo e imágenes
MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.
Surface Manager: maneja el acceso al subsistema de representación gráfica en 2D y

3D.
WebKit/Chromium: soporta un moderno navegador Web utilizado en el navegador

Android y en la vista Webview. En la versión 4.4, WebKit ha sido reemplazada por
Chromium/Blink, que es la base del navegador Chrome de Google.
SGL: motor de gráficos 2D.
Librerías 3D: implementación basada en OpenGL ES 1.0 API. Las librerías utilizan el
acelerador hardware 3D si está disponible, o el software altamente optimizado de
proyección 3D.
FreeType: fuentes en bitmap y renderizado vectorial.
SQLite: potente y ligero motor de bases de datos relacionales disponible para todas las
aplicaciones.
SSL: proporciona servicios de encriptación Secure Socket Layer (capa de conexión

segura).
Entorno de aplicación. Proporciona una plataforma de desarrollo libre para aplicaciones

con gran riqueza e innovaciones (sensores, localización, servicios, barra de notificaciones,
etc.). Esta capa ha sido diseñada para simplificar la reutilización de componentes. Las
aplicaciones pueden publicar sus capacidades y otras pueden hacer uso de ellas (sujetas a
las restricciones de seguridad). Este mismo mecanismo permite a los usuarios reemplazar
componentes.
Los servicios más importantes que incluye son:
Views: conjunto de vistas, (parte visual de los componentes).
Resource Manager: proporciona acceso a recursos que no están incrustados en el

código.
Activity Manager: maneja el ciclo de vida de las aplicaciones y proporciona un sistema

de navegación entre ellas.
Notification Manager: permite a las aplicaciones mostrar alertas personalizadas en la

barra de estado.
Content Providers: mecanismo sencillo para acceder a datos de otras aplicaciones

(como los contactos).
Una de las mayores fortalezas del entorno de aplicación de Android es que se aprovecha el
lenguaje de programación Java. El SDK de Android no acaba de ofrecer para su estándar
todo lo disponible del entorno de ejecución Java (JRE), pero es compatible con una
fracción muy significativa de este
Por último, por encima de estas capas se encuentra la capa de las aplicaciones, las cuales se
lanzan sobre la máquina virtual Dalvik/ART para garantizar la seguridad del sistema.
th
(1) Abraham Silberschatz, Peter Baer Galvin, Greg Gagne (2013). Operating System Concepts, 7
Edition. Ed Wiley.
th
(2) Andrew Tanenbaum, Herbert Bos (2015). Modern Operating System, 4 Edition. Ed Pearson.
(3) Jesús Tomás Gironés (2015). El gran libro de Android, 5ª Edición. Ed Marcombo.
(4) McLibre, Material Curricular Libre, http://www.mclibre.org
(5) The Open Group, Unix, http://www.opengroup.org/unix
(6) The Linux Kernel Archives, https://www.kernel.org
(7) Microsoft Windows, sitio oficial, https://www.microsoft.com/es-es/windows
(8) Android, sitio oficial, https://www.android.com/intl/es_es
(9) Kantar WorldPanel, Smartphone OS Sales market share,

http://www.kantarworldpanel.com/global/smartphone-os-market-share
(10) Dennis M. Ritchie, Ken Thompson, The Unix Time-Sharing System,

https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf
(11) El Sistema Operativo GNU, https://www.gnu.org
(12) Licencia Pública General GPL, https://www.gnu.org/licenses/gpl-3.0.html
(13) Linux Kernel Newbies, https://kernelnewbies.org
Tema 27. Gestión de entornos basados en
servidores con sistema Microsoft. Gestión
dominios. Active Directory. Protocolos
Guillem Arnau Beneito

Colegiado 0809
Active Directory es la implementación de Microsoft de un servicio de directorio, a la

que añade herramientas para facilitar la administración de usuarios y equipos de
complejas organizaciones, confiriéndole la naturaleza de dominio. Separa su
estructura física y lógica con el fin de facilitar su gestión. Se adapta fácilmente al
crecimiento o cambio de estructura de la organización gracias a la posibilidad de
añadir y configurar los controladores de dominio. El uso de estándares como DNS y
LDAP le dota de capacidades de conexión con otros sistemas no propios de Microsoft.
Es posible el uso de diferentes versiones de Windows, tanto de clientes como
servidores, permitiendo la actualización paulatina de los sistemas operativos sin tener
que renunciar a la potencia de la administración centralizada de usuarios y equipos. La
posibilidad de definir grupos, tanto de equipos como de usuarios, facilita enormemente
su gestión al poder agrupar objetos que compartan características, ya sean
funcionales, técnicas o ambas. Esta flexibilidad para la definición de los objetos
administrados se disfruta también en la parte administrativa, permitiendo que no haga
falta la existencia de súper administradores obligados a supervisar todos los aspectos
del dominio, pues se habilita la posibilidad de delegar permisos parciales a distintos
usuarios con el fin de reducir y especializar la gestión de todo el ámbito del dominio.
Además, se dota al dominio de la posibilidad de aplicar políticas de gestión tanto para
usuarios como equipos, con el fin de homogeneizar o particularizar configuraciones y/o
restricciones.
1. Dominios y directorios
La base sobre la que se construye una red de ordenadores Microsoft en una organización es
Windows Server. Sobre un servidor o un conjunto de servidores con este sistema operativo se
despliegan y construyen todas las funcionalidades y herramientas para administrar tanto recursos
físicos (puesto cliente, servidores, impresoras…) como humanos (usuarios, grupos y roles).
Para facilitar la administración y gestión de los ordenadores y servidores que forman parte de la
organización nace el concepto de dominio, que no es más que el dotar a uno o varios equipos de la
red de herramientas para realizar la gestión administrativa y de seguridad de forma centralizada. Si
bien ésta es la definición más genérica, Microsoft le otorga más propiedades, las cuales veremos
cuando tratemos los componentes de Active Directory.
Un directorio es una estructura jerárquica que almacena y organiza la información sobre objetos
existentes en la red de la organización, tanto usuarios como equipos, permitiendo:
• A los administradores: gestionar el acceso de usuarios a los recursos de dicha red.
• A los usuarios: tener un único punto de entrada a la red de la empresa, de forma que
pueda tener disponible en cualquier puesto físico todos los recursos que necesite.
El directorio se apoya en un repositorio: una base de datos que contiene los objetos administrados,
optimizada para operaciones de lectura, cualidad que le permite búsquedas de grandes volúmenes
de información así como con capacidades de exploración.
Hay muchas implementaciones de directorio, la mayoría basadas en el protocolo X500, el cual por
el tiempo sería reemplazado por LDAP (más ligero). La versión de directorio de Microsoft es Active
Directory Domain Services, aunque es más conocido por cómo se conocía con anterioridad a
Windows Server 2008, Active Directory (de ahora en adelante, AD). Así pues, en Active Directory
tenemos todas las características vistas de un directorio añadiendo otras funcionalidades, como la
distribución masiva de aplicaciones y actualizaciones de sistema a los ordenadores que se desee,
entre muchas otras.
2. Active Directory
Para empezar a construir un dominio para AD se debe instalar la funcionalidad de Directorio Activo
en una o varias máquinas Windows Server 2000 o posterior, pues es la primera versión desde la
que está disponible AD. El equipo (o equipos) en los que se realice la instalación se convertirá en
el Controlador de Dominio, el encargado de realizar las tareas de directorio vistas anteriormente. El
Gestión de entornos Microsoft. Active Directory
resto de los equipos de la red se convertirán en los clientes que podrán consultar la información
almacenada en el controlador.
El uso de Active Directory ofrece las siguientes ventajas:
• Asimilación e integración de DNS para resolución de nombres, con lo que se facilita la

identificación de los equipos del dominio.
• Potente motor de búsqueda de los objetos administrados por el dominio gracias al catálogo
global.
• Extensible. Se pueden añadir objetos administrados según las necesidades lo requieran.
• Uso de políticas (GPO’s, Group Policy Object). Facilitan la gestión de permisos de usuarios
y grupos sobre recursos.
• Escalabilidad. La infraestructura se puede adaptar al crecimiento de la organización

añadiendo dinámicamente nuevos controladores y/o dominios.
• Reparcelación de información. Los controladores compartirán la información almacenada,

reduciendo el tráfico de red debido a las consultas y reforzando la tolerancia a fallos.
• Seguridad: AD centraliza la autenticación. La definición del acceso a la que puede tener un

usuario y/o grupo es muy granular, se puede especificar a nivel de atributo de objeto.
• Interoperabilidad: El uso de estándares (como LDAP) le permite la conexión con otros

sistemas.
Para el diseño del dominio de Active Directory se debe partir de la estructura organizativa de la
empresa, así como del conocimiento de las características físicas y lógicas de la red, con el fin de
diseñar las dos estructuras que diferencia: las lógicas y las físicas. El separar ambas estructuras
permite que la gestión y consulta de los objetos definidos sea independiente de los componentes
elegidos para implementar la infraestructura que da soporte al dominio.
2.1. Estructuras físicas
El diseño de las estructuras físicas tiene que ir encaminado a dimensionar los componentes que la
integran para soportar el tráfico de red generado por el uso del dominio: inicios y finales de sesión
y replicaciones entre servidores son operaciones que requerirán de ancho de banda. Además,
puede darse el caso que la organización cuente con oficinas o departamentos alejados
físicamente, por lo que se deben ajustar los nodos que se ponen a disposición.
A continuación, se detallan los elementos que configuran la estructura física: sitios y controladores
de dominio.
2.1.1. Sitios
Los sitios (sites) representan la estructura física de la red. Están formados por los equipos
conectados entre sí por enlaces de alta velocidad, generalmente constituido por una o varias
subredes. Con la creación de los sitios se consiguen las siguientes ventajas:
• Los usuarios tienen un controlador cercano que permite una comunicación rápida,
principalmente para las tareas de autenticación.
• Replicación: Según el uso de la red y de las necesidades de actualización de los

controladores, se pueden establecer ventanas horarias de sincronización entre
controladores.
• Localización de servicios: Otros servicios de Microsoft, como por ejemplo Exchange,

pueden guardar en el controlador del sitio información que permita dirigir al usuario al
proveedor del servicio más cercano.
2.1.2. Controlador de dominio
Como se ha visto anteriormente, se trata de un equipo con Windows Server al que se le ha

instalado la funcionalidad de Directorio Activo. Realizará tareas de almacenamiento y de
replicación entre controladores. Es conveniente incorporar más de un controlador por dominio, con
el fin de asegurar la disponibilidad. Cada controlador contiene las siguientes particiones:
• Partición de dominio: Es la partición que contiene la información de todos los objetos del
dominio y que se sincroniza con el resto de los controladores del mismo dominio.
• Partición de configuración: Es la encargada de salvaguardar la topología del bosque y

estructura del dominio como, por ejemplo, las distintas conexiones entre los distintos
controladores en el mismo bosque. Cualquier controlador puede modificar esta
información, la cual será replicada al resto de controladores.
• Partición del esquema: Contiene las definiciones de las clases definidas para los objetos
que se pueden crear en el dominio. En un bosque sólo habrá un controlador que tendrá
permisos para modificar las definiciones. Se replicará al resto de los controladores, pues
deben ser conocedores, pero sólo en modo lectura.
• Partición de aplicaciones: Almacena datos específicos de aplicaciones que tiene permitido

el uso del directorio. Es opcional y se puede crear a posteriori de la instalación primera.
Los datos guardados en esta partición suelen ser administrados por la propia aplicación.
2.2. Estructuras lógicas
La estructura lógica de AD se encarga de proporcionar distintos elementos jerárquicos con los que
poder plasmar las características de la organización de forma totalmente independiente de la
infraestructura subyacente que le da soporte. Para facilitar la administración de los objetos

gestionados define los siguientes elementos:
2.2.1. Dominio
Es la unidad principal de la estructura lógica, almacena información exclusivamente de los objetos

que contiene, tanto componentes físicos como usuarios y agrupaciones de usuarios.
Un dominio necesita de uno o más controladores de dominio. Aunque originariamente no era así,
cualquier controlador puede efectuar cambios y replicarlos en el resto de los controladores. Se
podría decir que los dominios son unidades de replicación.
La existencia del dominio permite disfrutar de una serie de ventajas:
• Organización de objetos. AD permite organizar los objetos que gestiona mediante las
divisiones y subdivisiones que se creen oportunas (OU’s, Organizational Unit). Además, se
podrán aplicar políticas sobre objetos, grupos o OU’s que se considere necesarios de
forma totalmente independiente.
• Repositorio de información. La información almacenada podrá ser consultada por los

objetos del dominio, además de por objetos de otros dominios si así se configura, siendo el
alcance de este acceso parametrizable.
• Delegación de permisos administrativos. Incorpora múltiples formas de delegar

permisos que evita el tener varios administradores con elevados permisos de
administración. La delegación personalizada a grupos o usuarios para determinados
objetos o OU’s dota a AD de gran flexibilidad para su administración. Como el dominio en
sí también es un límite de seguridad, todos estos permisos en un principio se limitan al
propio dominio.
• Delimitación de seguridad. Configuración y directivas de seguridad del dominio no

sobrepasan su ámbito.
2.2.2. Árbol
Un árbol es un grupo de dominios que dependen de un mismo dominio raíz y que están
organizados formando una determinada jerarquía. Compartirán el sufijo del DNS que los identifica.
El primer de los dominios creados actuará como dominio raíz, mientras que los dominios que se le
vayan añadiendo para formar el árbol se convertirán en los dominios secundarios. Es una
estructura que puede ser válida para diferenciar distintos departamentos dentro de una misma
organización, independientemente de su localización.
Entre los dominios integrantes del árbol habrá una relación de confianza, la cual permitirá que un
usuario creado en un dominio sea reconocido en el momento que intente acceder a cualquier otro
dominio del árbol. Aun así, los dominios mantendrán su independencia administrativa, de forma
que los administradores de un dominio no pasan a ser administradores de los otros dominios del
árbol. Por último, las políticas no serán replicadas automáticamente.
2.2.3. Bosque
Un bosque es un grupo de uno o más dominios AD que comparten una estructura lógica, esquema
de directorio (tanto las clases de los objetos que se pueden definir como sus atributos),
configuración de directorio (sitios y replicaciones) y un catálogo global (se analizará un poco más
adelante).
El uso de varios dominios en un sólo bosque es válido para organizaciones en las que si bien
queremos mantener una estructura homogénea en la definición de los dominios y árboles, se
desea mantener cierta independencia en la administración de los recursos de cada dominio y
aislarlos del resto.
2.2.4. Unidades organizativas
Una Unidad Organizativa (OU) es un contenedor, una carpeta que puede contener a otros objetos
de AD. Es el símil de carpeta (o antiguamente, directorio) en un sistema de ficheros. Por lo tanto,
puede almacenar objetos que representen a equipos, impresoras, usuarios, grupos de usuarios,
otras OU’s…
Los motivos que pueden aconsejar crear OU’s son los siguientes:
• Jerarquía administrativa. Permite agrupar en una única unidad todos aquellos objetos
que se considere que tienen una fuerte relación. La jerarquía de OU’s anidadas (unas
dentro de otras) que se cree es independiente de un dominio a otro dentro del mismo árbol.
Esta flexibilidad posibilita que se pueda intentar adaptar la estructura de OU’s con el
modelo administrativo de la organización.
• Políticas de grupo. Las políticas de grupo son un conjunto de reglas que determinan las
capacidades que tendrán los equipos y usuarios que están contenidos en la OU. Dichas
reglas pueden establecer por ejemplo, qué aplicaciones están disponibles para un grupo
de usuarios, dónde se guardan los documentos, o bloquear las modificaciones en el
escritorio local.
• Delegación de la administración. Cada OU se puede administrar de forma

independiente, es posible asignar la capacidad de gestión total o parcial de cualquier OU a
un usuario o grupo de usuarios.
Existe un conjunto de contenedores especiales que son creados por defecto en la instalación de
AD y no se pueden eliminar. No les son aplicables políticas de grupo y representan a distintos tipos
de objetos. Son los siguientes:
• Domain: Es el contenedor raíz de la jerarquía.
• Built-in: Contenedor por defecto para las cuentas de administradores de servicios.
• Users: Lugar por defecto para las nuevas cuentas de usuarios y grupos creadas.
• Computers: Localización por defecto de las nuevas cuentas de equipos creadas.
• Domain Controllers OU: Contenedor por defecto para las cuentas de equipos de los
controladores de dominio.
Si bien estos son los contenedores donde se crean por defecto los distintos objetos explicados, se
puede modificar el contenedor destino establecido por defecto.
2.3. Catálogo global
El catálogo global es el conjunto de todos los objetos de un bosque de Active Directory.
Un servidor de catálogo global es un controlador de dominio. Almacenará una copia íntegra de

todo el directorio del dominio al que pertenece y una copia parcial (y de sólo lectura) de los otros
dominios de la estructura organizativa a la que pertenezca (bosque, árbol…). La copia parcial se
refiere a un subconjunto de la información almacenada de los objetos y que corresponden a los
atributos que se consultan con mayor frecuencia. Esta característica ayuda a mejorar el
rendimiento de la red, pues se evita consultas innecesarias a otros controladores de dominio.
Debe existir como mínimo un servidor de catálogo global en cada dominio, pudiendo añadir
posteriormente a cualquier otro controlador como servidor de catálogo global.
Las principales funcionalidades del catálogo global son:
• Búsqueda de objetos: Como se acaba de ver, el catálogo permitirá búsquedas de

información de cualquier objeto dentro de su estructura organizativa, sea del propio
dominio o no.
• Autenticación de nombre principal de usuario (UPN, User Principal Name). En el

momento de iniciar sesión, el usuario no especificará el nombre completo de su usuario en
AD en formato <nombre>@<dominio>. El equipo en el que esté intentando iniciar sesión
realizará la consulta al controlador del dominio al que pertenezca. En caso de que no
pertenezca a dicho dominio, es el catálogo global el que le indicará en que dominio debe
realizar la búsqueda para su validación.
• Validar referencias de objeto de un bosque. En el momento en el que un controlador de

dominio necesite validar una referencia a un objeto de otro dominio hará uso del catálogo
global.
• Proporcionar información de pertenencia a grupos universales en estructuras

organizativas. El controlador de dominio puede resolver la pertenencia de un usuario de
su dominio a un grupo local o global, pero en el caso de que se trate de un usuario de un
grupo universal, el controlador deberá consultar con el servidor de catálogo global para
determinar la pertenencia del usuario a grupos universales de otros dominios.
3. Estándares
A partir de la versión de Windows Server 2000, AD ha introducido en su desarrollo protocolos y

estándares ya existentes con el fin de mejorar su interoperabilidad con otros sistemas. Los más
destacados son los siguientes:
3.1. DHCP
La convivencia de varios servidores DHCP en el mismo dominio puede provocar conflictos en caso
de que intenten gestionar los mismos rangos de direcciones. AD intenta evitar que se produzca
esta situación de dos formas distintas, según el servidor DHCP que está intentando entrar
pertenezca al dominio o no:
• Si el servidor es miembro del dominio (puede ser un controlador de dominio) pregunta a AD

el listado de servidores autorizados (direcciones IP). Si el servidor que realiza la consulta
no encuentra su IP en el listado, finaliza automáticamente el servicio de DHCP.
• En caso de que no sea miembro del dominio, el servidor enviará un mensaje solicitando
información del nodo raíz en el que se encuentra configurado el servicio de DHCP. Los
servidores DHCP autorizados responderán con un mensaje indicando cuál es el nodo raíz
autorizado. A continuación, el servidor que ha iniciado el diálogo consulta en el nodo en el
que se le ha respondido por la lista de servidores autorizados, actuando de la misma forma
que se ha visto en el punto anterior.
El listado de servidores autorizados es gestionado por un grupo de administradores autorizados.

Hasta que un servidor DHCP que ingresa en el dominio no esté en dicha lista, no podrá proveer a
los clientes que les solicite configuración de red.
3.2. DNS
El estándar se explica con más detalle en el tema correspondiente. Vamos a centrarnos en la

importancia de dicho protocolo para AD.
Active Directory utiliza DNS para identificar a su controlador de dominio y aprovecha el diseño del
espacio de nombres de DNS en el diseño de los nombres de dominio.
Cualquier controlador de dominio puede convertirse en servidor de DNS. En el momento de crear

el dominio (se crea al instalar la funcionalidad de controlador de dominio a un Windows Server) se
debe especificar su nombre. A partir de este momento, todos los equipos que se añadan al dominio
se les podrá hacer referencia siguiendo la nomenclatura de DNS, <nombre_equipo>.<dominio>.
Esta forma de hacer referencia a dominios y equipos implica que ambos estén representados como
objetos en AD y como nodos en DNS.
Así pues, AD usará DNS para la resolución de los nombres en su dominio. En el momento en el
que se realice un inicio de sesión, el equipo deberá localizar un controlador de dominio. Para ello,
efectuará una búsqueda DNS para obtener la dirección de dicho controlador.
Aunque la nomenclatura es idéntica en ambos ámbitos, representan distintas ideas:
• DNS almacena zonas y registros de recursos, mientras que AD almacena información de

dominios y sus objetos. Ambos sistemas usan una base de datos para la resolución de
nombres.
• Mientras que DNS resuelve nombres de dominio y de equipos a registros de recursos a

partir de peticiones recibidas por los servidores DNS, las cuales se transforman en
consultas DNS a bases de datos DNS, AD resuelve nombres de objetos del dominio a
registros de objetos por peticiones recibidas por el controlador de dominio a partir de, o
bien consultas de LDAP, o bien peticiones de modificaciones de la base de datos de AD.
Por lo tanto, el nombre de objeto que representa a un ordenador en Active Directory se encuentra
en un espacio de nombres diferente que el registro de recurso que representa al mismo equipo en
DNS.
3.3. LDAP
El protocolo LDAP es el núcleo de Active Directory, siendo el único protocolo de conexión que
soporta. Se ha convertido en la vía principal que usan el resto de sistemas para integrarse con AD.
Debido a esta circunstancia, se considera en Microsoft que es tanto un protocolo como una API.
LDAP (Lightweight Directory Access Protocol) es un protocolo del nivel de aplicación que facilita el
acceso a un servicio de directorio distribuido en un entorno de red, entendiendo como directorio un
conjunto de objetos con atributos organizados de forma jerárquica.
La versión actual de LDAP es la v3 y tiene su especificación técnica en el RFC 4510, el documento

base es el RFC 4511, la especificación de modelos el RFC 4512 y los aspectos referentes a
seguridad y métodos de autenticación se encuentran en el RFC 4513.
El servicio de LDAP se basa en un modelo cliente/servidor. Los servidores LDAP contienen la

información que conforma el árbol de directorios. En una conexión típica, el cliente solicitará una
acción o consulta a un servidor LDAP (a un controlador de dominio). El servidor, si puede
satisfacer la petición la ejecutará, en caso contrario se referenciará al cliente el servidor LDAP que
pueda resolver la petición.
LDAP puede utilizar tanto TCP como UDP, usando por defecto el puerto 389. Se establecen una
serie de operaciones con las que el cliente puede solicitar operaciones al servidores, tales como
crear, borrar, actualizar o consultar.
El formato más extendido para representar la información almacenada en LDAP es LDIF (LDAP
Data Interchange Format), aunque la información que trata el protocolo es binaria.
3.3.1. Estructura
Cada entrada del directorio contiene un conjunto de atributos, los cuáles pueden contar con más
de un valor. Los atributos que pueden presentar un registro se encuentran definidos en un
esquema.
Un registro estará identificado mediante dos formas distintas:
• Por su Distinguished name (DN), el cual lo identificará según en qué parte del árbol se
encuentre.
• De forma opcional, por un UUID, que lo identificará de forma unívoca en todo el árbol. En
el caso de AD, tal como veremos, se trata del GUID.
El DN está compuesto por 2 o 3 partes. La parte derecha está formada por la raíz del objeto,
mientras que la izquierda corresponde a la hoja en la que se encuentra el registro. Dichas partes
son, de derecha a izquierda:
• DC: Domain Component. Especifica en que dominio se encuentra el objeto que queremos
representar. Un ejemplo podría ser “dc=airius, dc=com”, se trataría del nombre DNS de la
compañía en la que trabaja un usuario.
• OU: Organization Unit. Esta parte es opcional. Correspondería a los distintos niveles
jerárquicos en los que se quiere dividir la organización. Si no se quisiese realizar ninguna
clasificación se omitiría. Como ejemplo podríamos suponer que el objeto que buscamos se
encuentra en el segundo nivel de la jerarquía de la organización: “ou=Contabilidad,
ou=Departamentos”.
• CN: Common Name. Literalmente, el nombre común, el nombre del objeto que estamos
definiendo. En AD es válido para cualquier objeto y los contenedores creados por defecto
por AD. El resto de OU’s que se creen y se incluyan en en DN deberán constar como OU’s.
Siguiendo el ejemplo, la organización podría contar con el usuario “cn=Foo Foo”.
De esta forma, el DN completo del usuario sería “cn=Foo Foo, ou=Contabilidad,

ou=Departamentos, dc=airius, dc=com»”.
3.3.2. Origen
LDAP tiene su origen en el estándar X500, que es un conjunto de protocolos promovido por la ITU.
X500 es un directorio que contiene información de forma jerárquica y categorizada, incluyendo
nombres, directorios y números telefónicos. Requiere de la pila de protocolos OSI.
Con la intención de ofrecer una alternativa más ligera surgió LDAP, el cual trabaja sobre TCP/IP.
Se ideó como protocolo para el acceso a los servicios de X500, pero por el paso del tiempo acabó
definiendo también la parte servidora. El éxito de la implantación de las redes TCP/IP sobre las
redes OSI provocaron que se extendiera el uso de LDAP sobre X500. Actualmente los protocolos
X500 pueden ser configurados para trabajar en redes TCP/IP.
3.4. Kerberos
Kerberos es un protocolo de autenticación en una red de ordenadores que funciona mediante el

uso de ticket’s, los cuales permiten que los nodos se comuniquen a través de una red no segura
demostrando su identidad el uno al otro de una manera segura. Para ello Kerberos crea una clave
simétrica. Necesita de un tercer actor confiable.
Los tres participantes en una comunicación mediante Kerberos son el cliente, el servidor y el KDC,
Key Distribution Center.
El KDC está compuesto por:
• El servidor de autenticación (AS, de Authentication Server).
• El servidor de concesión de ticket’s (TGS, de Ticket Granting Server).
3.4.1. Funcionamiento
Para que el cliente pueda obtener el servicio que requiere del servidor del dominio, previamente ha
de realizar una negociación que consta de 3 fases:
• Negociación con el AS. La secuencia es la siguiente:
Para el inicio de sesión de un usuario en el dominio, se hace uso de su nombre de

usuario y contraseña. El puesto cliente en el que se encuentra genera una clave hash a
partir de la contraseña y se la guarda.
El cliente envía al AS la petición de servicio del usuario junto con el nombre de usuario.
El AS busca al usuario en su base de datos. Si es encontrado, se devuelve un mensaje

Ticket to Get Tickets (TGT) el cual es válido para la comunicación dentro del dominio
con una validez de 10 horas renovables (tiempo establecido por defecto, es
configurable).
El cliente guarda en la memoria local el TGT, pues se usará cada vez que se necesite
solicitar un servicio a cualquier servidor del dominio.
• Negociación con el TGS. Una vez obtenido el TGT por parte del cliente:
El cliente se comunica con el TGS en el momento que necesita realizar una petición a
un servidor, proporcionando el TGT.
El TGS autenticará el TGT del usuario y, si todo está correcto, enviará dos nuevos
mensajes: un nuevo ticket (que incluye el ID de cliente, la dirección de red del cliente,
el período de validez y una clave de sesión) y otro con sólo la clave de sesión, la cual
será válida sólo para el cliente y el servidor del servicio que se está solicitando.
El ticket estará cifrado con la clave secreta del servidor, de forma que sólo se pueda
desencriptar por aquél.
• Negociación con el servidor. Una vez el cliente recibe los 2 nuevos mensajes:
El cliente ya puede iniciar la comunicación con el servidor. Para ello envía 2 nuevos
mensajes: uno con el ticket que le acaba de proporcionar el TGS, y otro con una marca
de tiempo firmado con la clave del segundo mensaje del TGS.
El servidor desencripta el ticket de servicio y conoce qué cliente es el que quiere

conectar.
Del ticket de servicio obtiene también la clave con la que desencriptar el segundo
mensaje. A la marca de tiempo que obtiene, le suma una unidad y lo firma con la clave
cliente/servidor.
El servidor envía al cliente la marca de tiempo modificada y cifrada.
El cliente desencripta y confirma que el resultado de la marca de tiempo es el

esperado.
A partir de ese momento se establece la confianza entre cliente y servidor y el cliente

podrá empezar a usar el servicio deseado.
3.4.2. Nuevas características
Al igual como evoluciona Windows Server añadiendo nuevas características y funcionalidades,

Kerberos también ha ido renovándose. Si bien en las dos versiones 2008 apenas se introdujeron
novedades, en la versión 2012 presenta las siguientes:
• Mejoras en la autenticación. Al incrementar la cantidad y complejidad de la información

necesaria para realizar un inicio de sesión tal y como estaba diseñado Kerberos, puede
provocar errores falsos de autenticación. En el momento que se recupera todos los grupos
del que el usuario es miembro, ya sean del dominio, universales o asociados, puede
provocar que el ticket que se genera con toda esta información exceda del buffer que los
servidores tiene asignado para procesar el mensaje, provocando errores de autenticación.
Para evitarlos se adoptaron una serie de medidas:
Se comprime la información de pertenencia a grupos de dominio.
Se aumenta el buffer destinado a procesar el ticket de servicio proporcionado por el

KDC.
Se habilita a KDC para que notifique la existencia de tickets grandes en el momento

que los tickets que está generando se acerquen o superen un umbral determinado de
longitud.
• Mejoras en la administración. Se permite que una autenticación mediante tarjeta

inteligente permita la autenticación fuera del sitio. En versiones anteriores no era así. Se
consigue usando un controlador de dominio concreto que facilitará TGT’s para los recursos
externos al sitio.
Otras mejoras introducidas son:
• Protección ampliada. Se dota al cliente y servidor de un conjunto de reglas para el

establecimiento de un canal seguro entre ambos terminales.
• Notificaciones. Nueva forma de autenticar en AD. Los KDC pueden generar tickets a partir
de vales de servicio proporcionado por un origen de confianza.
• FAST. Se trata de un canal protegido que se crea entre el cliente Kerberos y el KDC.
• Autenticación compuesta. Basándose en el FAST, permite que los clientes Kerberos

proporcionen el TGT del dispositivo. De esta forma los KDC pueden crear vales de servicio
con los datos de autorización para aquellos servicios que los requieran. Estos vales serán
usados para generar tickets que incluyan los grupos y notificaciones de dispositivos que
puedan usarse para el inicio de sesión.
3.4.3. NTLM
Con anterioridad al uso de Kerberos (desde Windows Server 2000) se utilizaba el protocolo de
autenticación NTLM (NT Lan Manager), en el que el servidor se debía conectar cada vez a un
controlador de dominio para autenticar al cliente.
Actualmente NTLM se sigue utilizando por motivos de compatibilidad de máquinas con sistemas
operativos anteriores a Windows 2000. Si todas las máquinas del dominio son iguales o posteriores
a Windows 2000/XP, el protocolo de autenticación habilitado por defecto es Kerberos.
3.4.4. Ventajas
Las principales ventajas del uso de Kerberos son:
• Autenticación delegada. Los servicios que se ejecutan en sistemas operativos Windows

permiten que se delegue el acceso a determinados recursos en nombre del cliente que
está requiriendo los recursos. Kerberos y NTLM incorporaran mecanismos para gestionar
esta circunstancia.
• Inicio de sesión único (Single Sign on). Una vez iniciada la sesión se van gestionando los
permisos para el acceso a los distintos servicios, no hace falta autenticarse a cada
necesidad de servicio.
• Interoperabilidad. El uso de estándares permite la comunicación con otros sistemas que

usen Kerberos como sistema de autenticación.
• Mayor eficacia de autenticación para servidores. El hecho de no tener que comunicar

con un controlador a cada petición de un cliente permite agilizar el proceso de
establecimiento de conexión con dicho cliente.
• Autenticación mutua. En cualquier momento, cualquier entidad en extremo de la conexión

puede comprobar que la otra entidad es quien dice ser.
4. Niveles funcionales
Como todo software, los sistemas operativos de Microsoft (y entre ellos los Windows Server)
evolucionan con el tiempo, corrigiendo errores y añadiendo nuevas funcionalidades. En un sistema
en red en el que múltiples equipos deben comunicarse entre si este punto cobra vital importancia,
pues para poder disfrutar de una nueva funcionalidad los equipos implicados deben estar
evolucionados en el mismo grado, o en su defecto, establecer unos mínimos sobre los que
establecer la comunicación o la prestación de un servicio.
Los niveles funcionales de Active Directory son una forma de determinar qué características están
disponibles en un dominio o bosque. Se basan en las características nuevas que ofrece cada
versión de Windows Server a partir del 2000. Los controladores de dominio tienen que estar como
mínimo en el nivel funcional que se ha determinado para el dominio o bosque.
La evolución de un nivel funcional no tiene fácil vuelta atrás, en el momento que se evoluciona el
presente nivel funcional, no se puede restablecer, a excepción de casos muy concretos y
específicos.
Windows 2000 Server
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Figura 1. Niveles funcionales de dominio
En la Figura 1 se representa cada nivel funcional que versiones de Windows Server soporta como
controladores de dominio. Por ejemplo, si se está en un funcionamiento de Windows Server 2003,
la única versión que no será soportada en un controlador de dominio será Windows Server 2000.
4.1. Niveles funcionales de dominio
Según el nivel funcional en el que se encuentren los controladores de un dominio se dispondrá de

unas características u otras. A continuación, se enumeran algunas de las principales según en
nivel en el que se encuentre funcionando el dominio:
• Windows 2000: Como principales características encontramos:
Grupos universales habilitados para grupos de distribución y seguridad.
Anidación de grupos.
Habilitada la conversión entre grupos (como por ejemplo, de grupo de seguridad y

distribución).
• Windows Server 2003: Todas las vistas en el modo funcional anterior más las siguientes:
Capacidad de especificar la ubicación de los contenedores de usuarios y grupos.
El administrador de autorización puede almacenar directivas de autorización.
Delegación segura de credenciales por parte de aplicaciones.
Atributo en el objeto usuario con la hora del último inicio de sesión.
Posibilidad de cambiar el nombre del controlador de dominio.
• Windows Server 2008: Todas las explicadas en el modo funcional anterior, añadiendo:
Mejoras en la información almacenada de inicios de sesión de usuarios.
Replicación de SYSVOL (directorio local donde se almacena de forma distribuida la

información de directorio) más sólida y detallada.
Incorporación de AES 128 y 256 para Kerberos.
Nuevas directivas para contraseñas, como la posibilidad de especificar políticas de

contraseñas para usuarios y grupos del dominio.
• Windows Server 2008 R2: Todas las explicadas en el nivel anterior, más la siguiente:
Incorporación de un entorno de identidades federadas: se almacena el modo de inicio

de sesión (tarjeta inteligente o usuario/contraseña) dentro del token de Kerberos para
cada usuario. Si esta función esta activada, en cualquier momento que una aplicación
necesite validar al usuario puede extraer la información almacenada en el token.
• Windows Server 2012. Las vistas hasta ahora, añadiendo:
El KDC añade compatibilidad para notificaciones y autenticación compuesta. Para ello,

el KDC añade dos configuraciones nuevas para las plantillas administrativas:
proporcionar siempre notificaciones y errores de solicitudes de autenticación sin
blindar.
• Windows Server 2012 r2. Este nivel funcional modifica:
Los usuarios protegidos del dominio no podrán usar NTLM para autenticarse.
Kerberos no podrá usar cifrados DES o RC4.
La cuenta de usuario no se podrá delegar mediante Kerberos.
El TGT pasa a tener un valor predeterminado de 4 horas (en vez de las 10 vistas
anteriormente).
4.2. Niveles funcionales de bosque
Análogamente a la influencia de la versión del sistema operativo de los controladores de dominio

en el nivel funcional en el que se encuentra dicho dominio, también influyen en el nivel funcional en
el que puede trabajar el bosque.
Las características más importantes de los distintos niveles funcionales son las siguientes:
• Windows Server 2003:
Posibilidad de establecer confianzas entre bosques.
Se permite cambiar el nombre de un dominio.
La réplica de miembros de grupo se hace de forma individual en vez del grupo

completo (replicación de valor vinculado). De esta forma se minimiza tráfico de red
(sólo se copian la información de los objetos necesarios) y aumenta la fiabilidad de la
réplica.
Posibilidad de incluir controladores de dominio de sólo lectura (RODC).
Con el fin de habilitar la autorización basada en roles, se crean dos plantillas de tipos
de grupo para instanciar, llamadas grupos básicos de aplicación y grupos de consulta
LDAP.
Se da nueva utilidad a atributos de objetos en el esquema y se eliminan otros.
• Windows Server 2008: Todas las características del nivel funcional anterior. No se añaden
nuevas.
• Windows Server 2008 R2: Todas las características anteriores, añadiendo:
Papelera de reciclaje: Se permite la restauración completa de objetos eliminados.
nuevas.
nuevas.
5. Relaciones de confianza
Una confianza es una relación entre dominios que permite que los usuarios de un dominio tengan
permisos de acceso en otro dominio.
Todas las relaciones que se establecen entre dominios de bosques a partir de Windows Server
2000 son bidireccionales y transitivas. Bidireccionales porque una vez establecida la relación entre
dos dominios, los usuarios de uno tienen acceso al otro. Transitivas porque si el dominio A
establece una relación con el dominio B, y éste a su vez establece una nueva relación con el
dominio C, los usuarios del dominio A pueden acceder al dominio C y viceversa, puesto que A y C
confían en B.
La autenticación del cliente de un dominio sobre un servicio proporcionado por un servidor del
dominio en el que se confía es gestionada por Kerberos.
5.1. Objetos del nivel de confianza
Las relaciones de confianza entre dominios se representan mediante Objetos de Dominio de

Confianza (TDO, de sus siglas en inglés Trusted Domain Object). Cada nueva relación crea un
TDO único que se almacena en su dominio. Cada registro contiene información referente a los
nombres de dominios recíprocos, tipo y transitividad de la relación o atributos para identificar los
espacios de nombres de confianza en el bosque asociado.
Para poder establecer la relación de confianza se deberá contar con permisos de administrador en
ambas entidades. Se generará una contraseña de confianza segura que se deberá proporcionar a
los dos dominios que forman la relación.
5.2. Tipos de confianza
Existen 4 tipos de relaciones de confianza, las cuales se detallan en la Tabla I.
Todos los tipos de confianza de la Tabla I son unidireccionales o bidireccionales, es configurable

según la necesidad.
Tabla I. Tipos de relaciones de confianza
Tipo de confianza Transitividad Características
Válida para accesos a recursos de dominios

de Windows NT 4.0 o dominios de bosques
Externa Transitiva
diferentes que no tengan establecida una
confianza de bosque.
Válida para relaciones entre dominios en

Kerberos Transitiva / No transitiva nivel funcional Windows Server 2008 y un
dominio Kerberos no Windows.
De bosque Transitiva Válida para relaciones entre bosques.
Válida para mejorar el tiempo de inicio de

Directa Transitiva sesión entre dos dominios que están
separados por dos árboles de dominios.
5.3. Transitividad de confianza
Si bien la transitividad se incluye como un mecanismo para facilitar la gestión de acceso de

usuarios a servicios u objetos de otro dominio, puede darse el caso en el que se necesite aplicar
ciertas restricciones o bien vengan dadas por la naturaleza de los dominios que se quiere
comunicar.
5.3.1. Confianzas transitivas
Desde Windows Server 2000, en el momento que se añada un nuevo dominio a un bosque se crea
automáticamente una relación de confianza bidireccional y transitiva con el nodo padre del
dominio.
En la Figura 2 se muestra un ejemplo de qué implica la relación entre los dominios de un bosque.
Según se han ido añadiendo dominios hijos a los dominios padre de cada árbol (A y 1) se han
establecido confianzas transitivas entre ellos. En el momento que se establece la relación de
confianza entre los bosques (relación entre el Dominio A y el Dominio 1), automáticamente
cualquier usuario validado en un dominio del bosque puede acceder a los recursos proporcionados
por cualquier otro dominio. En la figura se hace hincapié en que, por ejemplo, los dominios 2 y C
que previamente no tenían relación, ahora si la tienen.
Además de las confianzas que se crean automáticamente al añadir un dominio a un árbol se

pueden crear las siguientes confianzas:
• Confianza directa: Se establece entre dos dominios de un mismo bosque, con el fin de
reducir el tiempo de inicio de sesión, pues las consultas de validación se realizarán
directamente sin tener que navegar por el árbol. En la Figura 2, sería el caso en el que se
quisiera acelerar el acceso entre los dominios B y C.
• Confianza de bosque: La establecida entre dos dominios raíz del bosque.
• Confianza de dominio Kerberos: La establecida entre un dominio Active Directory y entre

un dominio Kerberos V5 no Windows.
Dominio A Dominio 1
Dominio B Dominio C Dominio 2
Dominio D
Figura 2. Ejemplo de confianza transitiva entre dominios
5.3.2. Confianzas no transitivas
Se establecen de forma explícita. Sólo es válida para los dos dominios que la conforman, por lo
que no es extensible al resto de dominios del bosque. Son unidireccionales, si se quiere configurar
una relación bidireccional se deben crear dos relaciones unidireccionales, una en cada sentido.
Son las únicas posibilidades existentes si se quiere establecer una relación de confianza entre:
• Un dominio en nivel Windows 2000 o superior con un dominio Windows NT.
• Un dominio en nivel Windows 2000 o superior de un bosque y un dominio de otro bosque si

ambos bosques no tiene establecida una relación de confianza.
6. Objetos
Todas las características y funcionalidades que ofrece Active Directory tienen la finalidad de
facilitar la gestión de los distintos objetos que representan a las distintas entidades que conforman
la organización (usuarios, equipos, impresoras…). Mediante las distintas estructuras que se han
visto anteriormente, se pueden organizar los objetos de forma jerárquica, de forma que represente
lo mejor posible a la estructura de la organización que se está administrando. Esta administración
se realiza interactuando con el Directorio Activo.
Los objetos más relevantes que se pueden crear y administrar en AD son los que siguen.
6.1. Usuarios
Las cuentas de usuario de AD pueden representar tanto a personas físicas como a cuentas de
servicio necesarias para alguna aplicación que necesite un usuario de dominio.
A las cuentas de usuario se les asigna un identificador de seguridad (SID) compuesto por un prefijo
común a todas las cuentas del dominio, y un sufijo que es un identificador único en el dominio, de
forma que la unión de las partes proporciona un identificador único para el objeto. En el momento
en que un objeto se traslada de dominio, cambia su SID por pertenecer a otro dominio.
Además del SID los objetos también reciben otro identificador, el GUID. Es un identificador de 128
bits que identifica universalmente al objeto. Este identificador no cambia nunca, va asociado
siempre al objeto.
Las funciones principales de una cuenta de usuario son:
• Autenticar la cuenta del usuario.
• Autorizar o denegar el acceso a recursos del dominio según se haya establecido mediante
los permisos asignados al recurso.
Además de las cuentas que se puedan crear en un dominio, el centro de gestión de AD incorpora 3
cuentas por defecto:
• Administrador: Es la primera cuenta que se crea en el dominio. Es la que tiene control total
del dominio. Sólo se debería usar para tareas administrativas.
• Invitado: Es una cuenta que por defecto está deshabilitada y que sólo permite iniciar sesión
en el dominio. Se le pueden asignar permisos al igual que a cualquier otra cuenta.
• Asistente de ayuda: Tiene acceso limitado al equipo, y se crea en el momento se solicite

una sesión de Asistencia remota. La cuenta se elimina en el momento que no haya
ninguna petición de ayuda activa.
En la creación de un usuario del dominio se da la posibilidad de introducir gran cantidad de

información del usuario:
• Entre la más básica encontramos nombre y apellidos o el nombre a mostrar (por si se

quiere introducir alguna modificación a la mera concatenación de los anteriores).
• Información de inicio de sesión. Se establecerá el nombre de inicio de sesión, que deberá

ser único en el dominio. Junto con el nombre del dominio compondrá el Nombre Principal
de Usuario (UPN) bajo la forma de <nombre>@<dominio>. Además, por tema de
compatibilidad en sistemas anteriores a Windows 2000, se puede establecer otro nombre
de usuario para Netbios.
• Informaciones de restricción. Se puede restringir equipos y horarios en los que poder iniciar
sesión.
• Información administrativa. Organización a la que pertenece, puesto de trabajo, teléfonos…
6.2. Grupos
Un grupo es cualquier combinación de usuarios, equipos, contactos y otros grupos que se

administran de forma única. Sólo a usuarios y equipos se les considera como miembros del grupo.
Las ventajas de la utilización de los grupos son:
• Simplificación de la administración. Al asignar permisos a un conjunto de usuarios

mediante un grupo se evita tener que modificar los permisos de forma individual.
• Permite la delegación de la administración sobre todos los miembros de un grupo mediante

directivas de grupo.
• Se pueden crear listas de distribución para el grupo.
Los grupos se pueden clasificar por su ámbito y tipo. Veamos por qué se caracterizan:
6.2.1. Ámbito
El ámbito indica el alcance del grupo dentro del bosque o árbol. Existen tres ámbitos:
• Grupos locales de dominio:
Pueden incluir otros grupos (de cualquiera de los 3 ámbitos que se están tratando) y
cuentas de dominio.
A sus miembros sólo se les puede asignar permisos dentro del dominio.
Sólo serán visibles dentro del dominio.
• Grupos globales:
Pueden incluir usuarios del mismo dominio y grupos globales del mismo dominio.
A sus miembros se les pueden asignar permisos en cualquier dominio del bosque.
Tienen visibilidad en todos los dominios del bosque.
• Grupos universales:
Pueden incluir otros grupos (de cualquiera de los 3 ámbitos que se están tratando) del
bosque y cuentas de dominio del bosque.
A sus miembros se les pueden asignar permisos en cualquier dominio del bosque o
árbol de dominios.
Visibilidad en todo el bosque.
6.2.2. Tipos de grupo
En cuanto a las características de los grupos, se pueden crear dos tipos de grupos: de distribución
y de seguridad.
Los grupos de distribución se usan exclusivamente para el envío de correos mediante aplicaciones
de correo electrónico. No disponen de seguridad habilitada.
Los grupos de seguridad son los empleados para administrar a los usuarios. Con ellos se pueden
asignar permisos a los recursos para determinar quién puede tener acceso a un recurso y de que
forma (lectura, escritura…), y derechos para determinar que pueden hacer los integrantes del
grupo en el ámbito de un árbol o bosque.
Por defecto, los Windows Server a partir de 2003 incluyen una serie de identidades especiales a
los que se les hace referencia como grupos, aunque propiamente no sean tales. Aunque
representan a un conjunto de usuarios, no se puede editar sus características. Son los siguientes:
• Todos. Conjunto de usuarios que ha iniciado sesión.
• Inicio de sesión anónimo. Grupo de usuarios y servicios que hace uso de un equipo y sus
recursos sin usar un nombre de cuenta. Por defecto, no se incluyen en el grupo Todos.
• Red. Todo aquél que usa un recurso de red a través de la red (no de forma local en la
máquina que lo comparte) en ese momento.
• Interactivo. Conjunto de usuarios que han iniciado sesión en un equipo y utilizan los
recursos de forma local, no a través de la red.
Además de las identidades especiales AD crea por defecto dos clases de grupos en sendos
contenedores (agrupaciones lógicas de objetos): Builtin y Users. Mientras que los primeros tienen
un ámbito más local y tienen características semejantes a los tipos de usuario que se podrían
encontrar en un equipo local, los segundos tienen una perspectiva más amplia, gestionan permisos
a nivel de Directorio.
Algunos ejemplos de grupos Builtin son:
• Administradores. Grupo de usuarios con control total sobre los controladores de dominio.
• Usuarios. Los integrantes de este grupo pueden realizar las tareas más comunes como
ejecutar aplicaciones, usar impresoras, etc. Las cuentas que se crean en el dominio
formarán parte de este grupo.
• Operadores de cuentas. Pueden administrar cuentas de OU’s a excepción de la OU

Controladores de dominio y grupos de administración.
• Operadores de copia. Sus usuarios pueden realizar tareas de backup y restauración de

los controladores, aunque no tengan permisos para acceder a la información.
Entre los grupos que se pueden encontrar en el contenedor Users tenemos:
• Administradores del dominio. Sus miembros tienen control total sobre el dominio. El
usuario Administrador es miembro por defecto de este grupo.
• Usuarios del dominio. Contiene a todos los usuarios de dominio. Al crear una cuenta
forma parte de este grupo de forma predeterminada.
• Administradores de organización. Este grupo sólo aparece en los controladores del

dominio raíz del bosque. Sus integrantes tienen control sobre todos los dominios del
bosque.
• Propietarios del creador de directivas de grupo. Los miembros pueden cambiar la

directiva de grupo del dominio.
• Administradores de esquema. Los usuarios de este grupo pueden modificar el esquema

de AD.
6.2.3. Equipos
Al igual como AD administra usuarios creando y administrando los objetos que los representan,
también existen las cuentas de equipos. Puede tener cuenta de equipo cualquier ordenador a partir
de Windows XP para puestos cliente, y a partir de Windows NT y 2000 para servidores.
La información principal que se almacena en la cuenta de equipo es la que sigue:
• Nombre de equipo. También conocido como RDN. Nombre que lo distingue dentro de su
ámbito.
• Nombre anterior a Windows 2000. Por temas de compatibilidad hacia atrás, debe tener
un nombre de longitud inferior a 15 bytes.
• Sufijo DNS. Nombre completo del dominio al que se quiere unir el equipo.
• Nombre de host DNS. Concatenación del nombre de equipo y sufijo de DNS intercalando
un punto entre ambos, como ejemplo equipo1.dominio.es.
• Nombre principal de servicio (SPN). Valor que se genera a partir del nombre DNS del
host y que se usa en el proceso de autenticación entre el cliente y el servidor que provee
un servicio solicitado.
6.2.4. Unidades Organizativas
Tal y como se ha visto en la estructura lógica de AD, las OU’s facilitarán la organización de los
objetos que se acaban de analizar en este punto.
7. Políticas de grupo
Las políticas de grupo son un conjunto de reglas que establecen, de forma centralizada, el entorno
de trabajo, tanto configuraciones de los equipos como de los usuarios que inician sesión. Se
aplican configuraciones de registro, políticas de seguridad, ejecución de scripts, mapeo de
unidades de red…
Estas reglas se definen en los objetos de políticas de grupo (GPO’s), las cuales luego se vinculan
a sitios, dominios y OU’s. Los objetos que se encuentren dentro de cada uno de estos
contenedores aplicarán las GPO’s.
7.1. Administración
En el momento de la creación del dominio se establecen dos contenedores, uno que representa al
propio dominio y un segundo de nombre Domain Controllers, los cuales ya tienen asociados
sendas GPO’s, la primera llamada Default Domain Policy y la segunda Default Domain Controllers
Policy.
La política Default Domain Policy es la que contiene la configuración que se aplica a todas las
cuentas por defecto del dominio, incluye las políticas de password, la de bloqueos de cuenta y las
relacionadas con Kerberos. Estas políticas se aplican a todos los usuarios y equipos del dominio.
Por su parte, las Default Domain Controllers Policy contienen directivas que se aplican a los
controladores de dominio.
Aunque una GPO defina políticas para equipos y usuarios, cada tipo de objeto sólo aplicará
aquellas que le sean propias.
En la edición de una GPO se mostrará un árbol con los distintos apartados configurables. La
primera división que se realiza, como se acaba de comentar, es:
• Configuraciones de usuarios.
• Configuraciones de equipos.
Cada uno de estos grupos alberga nuevas divisiones:
• Directivas (Policies). Contiene opciones de configuración que aplica la directiva de grupo.

Están divididas de nuevo en tres agrupaciones:
Configuración de software: Incluye configuraciones para la instalación de aplicaciones.
Configuraciones de Windows: Incluye directivas de seguridad, ejecución de scripts o

redirección de carpetas.
Plantillas administrativas: Políticas basadas en la modificación de valores del registro.
• Preferencias. Son opciones de preferencia que pueden cambiar el valor de casi la totalidad
de opciones del Registro. A su vez, define dos grupos:
Configuración de Windows: Relativas a variables de entorno, accesos directos o

mapeo de carpetas.
Configuración del Panel de Control.
La principal diferencia entre ambas radica en que las preferencias son permanentes mientras no se
vuelvan a cambiar, mientras que las directivas se aplican cada inicio de sesión mientras estén
activas, refrescándose según el tiempo establecido y prevaleciendo sobre cualquier otra
configuración local del equipo.
7.2. Propagación de cambios
Cualquier modificación de una GPO no tiene una aplicación inmediata sobre los objetos a los que
debería afectar, pues primero se deben replicar entre los controladores de dominio a los que afecta
la modificación. Además, los puestos clientes tienen configurado un tiempo de refresco de 90
minutos (más un tiempo aleatorio de máximo 30 minutos). Los controladores de dominio preguntan
sobre modificaciones en las GPO’s cada 5 minutos. Este tiempo de refresco es configurable,
aunque no es recomendable disminuirlo por efectos en el tráfico de red y trabajo para los DC.
7.3. Orden de precedencia
Por defecto, una GPO se aplica desde el nivel en el que se define hacia los objetos de los
contenedores que incluye. Es decir, si se generase una GPO para un sitio, su dominio lo heredaría,
de ahí a las OU de primer nivel y a partir de ahí a tantas OU’s como haya en subniveles, hasta
llegar a los objetos, equipos y usuarios. A cada nivel el contenedor aplicaría las GPO’s del nivel del
que hereda, más las que le sean propias. En resumen, las GPO’s son hereditarias y acumulativas.
En el caso que en la propagación de “arriba a abajo” haya solapamiento, prevalecerá la política

que esté más cerca del objeto, sea equipo o usuario. Es decir, la OU en la que esté el objeto será
la que tenga más prioridad para establecer GPO’s.
En el caso que sea el contenedor al que se le apliquen más de una GPO y alguna de ellas se
contradigan, se deberá establecer mediante el gestor de GPO’s en qué orden se deben aplicar, de
más prioritaria a menos prioritaria.
Existen un par de parámetros aplicables a los contenedores que modifican el comportamiento de la

herencia en las GPO’s:
• Enforced (forzado). Rompe la herencia hacia los contenedores de más bajo nivel. Aquel
contenedor que tenga habilitada la propiedad evitará que un contenedor de más bajo nivel
que tenga una GPO que la contradiga sobrescriba la que éste contenedor tiene definido.
• Bloquear herencia (Block policy inheritance). El contenedor sobre el que se aplica no

propagará las GPO’s hacia los contenedores y objetos que contenga.
7.4. Grupos de seguridad
AL igual que todos los objetos de AD, las GPO’s también tienen listas de control para determinar
qué usuarios pueden realizar qué operaciones sobre las GPO’s. Por defecto, sólo los grupos de
administradores de dominio y de administradores de la organización pueden crear y vincular
GPO’s, pero existe la posibilidad de delegar estas tareas.
Se pueden delegar las siguientes tareas sobre GPO’s:
• Gestionar GPO’s individualizadas.
• Administración de GPO’s sobre contenedores:
• Crear GPO’s
• Gestionar filtros WMI (administrador de datos y configuraciones en equipos locales y

remotos) para poder trabajar en una GPO sobre las características disponibles en un
equipo dependiendo de la versión de Windows instalada.
(1) https://technet.microsoft.com
(2) https://social.technet.microsoft.com
(3) https://msdn.microsoft.com
(4) https://administracionsistemasoperativos201415.wordpress.com
(5) https://es.wikipedia.org
(6) http://somebooks.es
(7) Ferrer, F. y Terrasa, A. (2012). Administración avanzada de Windows Server 2008 R2.
Valencia: Universidad Politécnica de Valencia
Tema 28. Los sistemas de gestión de bases de
datos SGBD. El modelo de referencia ANSI. El
modelo relacional. El lenguaje SQL. Bases de
datos no relacionales. Bases de datos no
estructuradas. NoSQL
José Ramón Lozano Mínguez

Colegiado 0901
Una base de datos (1) es como un armario electrónico que contiene una serie de
archivos computerizados. El sistema de gestión de bases de datos permite a los
usuarios agregar, recuperar, modificar y eliminar archivos a la base de datos, así como
agregar, recuperar, modificar y eliminar datos en los archivos existentes.
Los sistemas de gestión de bases de datos son una pieza fundamental en los
sistemas de información y han ido evolucionando con éstos. Desde los ficheros planos
o indexados hasta las bases de datos NoSQL, pasando inevitablemente por las bases
de datos relacionales y el lenguaje de consulta SQL, ampliamente extendidos en los
sistemas de gestión y con un predominio, casi monopolio, del mercado de las bases
de datos durante décadas.
Necesidades de tratamiento multimedia dieron origen a las bases de datos orientadas

a objetos y bases de datos objeto-relacionales. La extensión del uso de Internet, la
aparición de gigantes tecnológicos y las necesidades de almacenamiento de grandes
cantidades de datos y estructuras dinámicas han hecho que otros modelos diferentes
al relacional empiecen a proliferar, lo que se ha venido en llamar las bases de datos
NoSQL (no solo SQL).
Los sistemas de gestión de bases de datos forman parte de los sistemas de información, de igual
forma que el hardware, los usuarios o los administradores del sistema. Cualquier organización
necesita de un sistema de información para tratar toda la información que requiere para su
funcionamiento. Los primeros sistemas de información automatizados ya almacenaban y trataban
la información mediante sistemas de ficheros que controlaba directamente el sistema operativo,
pero estos sistemas tenían inconvenientes, entre los que destacaban:
• Seguridad. Los ficheros podían ser accedidos por cualquier usuario e incluso eliminados
como un fichero más del sistema operativo.
• Concurrencia. Los accesos concurrentes a los ficheros podían generar inconsistencias.
• Dependencia de los programas respecto a los datos. Las aplicaciones tenían sus propios
ficheros de datos.
• Redundancia. Si teníamos varias aplicaciones, en ocasiones podían manejar los mismos

datos, y al tener que almacenarlas por separado para cada aplicación, se generaba
redundancia, que podía provocar inconsistencias.
Para resolver los problemas de los sistemas anteriores nace el concepto de base de datos, que
pretende unificar la información del sistema de información estructurado, sin redundancias y
manteniendo las distintas vistas de los usuarios. Una base de datos es una colección de datos
estructurados según un modelo que refleja las relaciones y restricciones de los mismos en la vida
real.
A su vez, los sistemas de gestión de bases de datos (SGBD) son herramientas software que:
• Permiten a las aplicaciones interactuar con las bases de datos (consultas, modificaciones,
borrados).
• Permiten a los administradores definir la estructura de los datos y las distintas vistas de
que éstos tienen las aplicaciones.
• Se encargan de mantener la seguridad, concurrencia, integridad e independencia de los

datos respecto a las aplicaciones que los consumen.
1. El modelo de referencia ANSI
En 1977 el grupo de trabajo ANSI/SPARC (American National Standard Institute/System Planing

And Requirement Commitee) propone una arquitectura de tres niveles (conceptual, interno y
externo) para la definición de un SGBD, cada uno con su esquema:
Sistemas de gestión de bases de datos
• Esquema conceptual. Visión del sistema de información según el punto de vista de la

organización, independiente del SGBD, que describe la información y funciones de la
organización.
• Esquema interno o físico. Representación en la memoria externa del ordenador de los

datos del sistema de información, tipos de registros almacenados, índices, representación
de los datos, etc. Es el nivel más cercano al almacenamiento físico de los datos.
• Esquema externo: Representación de los datos para una aplicación determinada.
El nivel externo es el más cercano a los usuarios, habrá muchas vistas externas según los usuarios
y sus necesidades de información. El nivel conceptual es una representación abstracta, y sólo
habrá una.
Figura 1: Los esquemas propuestos por ANSI/SPARC
Veamos un ejemplo de las tres vistas de una base de datos que almacena información de clientes
y productos de una empresa de producción.
Esquema conceptual:
Clientes: Número de cliente (numérico), nombre del cliente (carácter), compras año en curso
(numérico).
Productos: Código de producto (carácter), nombre del producto (carácter), precio de coste del
producto (numérico), precio de venta del producto (numérico), instrucciones de producción
(carácter, texto libre), componentes (carácter, texto libre).
Esquema interno:
Clientes:
NUMERO_CLI integer
NOMBRE_CLI string (100)
COMPRAS_ANYO real (10)
Productos:
COD_PRO string (15)
NOMBRE_PRO string (100)
PRECIO_COSTE_PRO real (10)
PRECIO_VENTA_PRO real (10)
INS_PRODUCCION TEXT
Esquema externo 1 (Gestión comercial):
Clientes:
NUMERO_CLI integer
NOMBRE_CLI string (100)
COMPRAS_ANYO real (10)
Productos:
COD_PRO string (15)
NOMBRE_PRO string (100)
PRECIO_VENTA_PRO real (10)
Esquema externo 2 (Control de producción):
Productos:
COD string (15)
NOMBRE string (100)
INS_PRODUCCION TEXT
Esquema externo 3 (Control de costes):
Productos:
CODIGO string (15)
NOMBRE string (100)
PRECIO_COSTE real (10)
En este momento es interesante introducir dos conceptos, el DDL (Data Definition Language o
lenguaje de definición de datos) y el DML (Data Manipulation Language o lenguaje de
manipulación de datos). Utilizaremos tanto un lenguaje de definición o como de manipulación de
datos distinto según el nivel en el que estemos trabajando. Los lenguajes serán más o menos
formales según el nivel.
Puede hablarse, por ejemplo, de un DDL conceptual como un lenguaje de definición de datos a
nivel conceptual. Dicho lenguaje no puede tener en consideración aspectos de representación
física de los datos o de técnicas de acceso, ya que estos aspectos pertenecen al nivel físico.
2. El sistema de gestión de bases de datos
El SGBD o DBMS (Sistema de gestión de base de datos, DataBase Management System) es el

sistema software que gestiona el acceso a la base de datos. El sistema recibirá las peticiones de
acceso a la base de datos del usuario y las ejecutará teniendo en cuenta el esquema externo del
usuario, así como los esquemas conceptual e interno.
Sus funciones son las siguientes:
• Describir los distintos esquemas de la base de datos.
• Manipular la base de datos, recuperación y modificación de la información.
• Administrar la base de datos. Los sistemas ponen a disposición del DBA (administrador de
la base de datos, DataBase Administrator) una serie de utilidades para llevar a cabo las
tareas de administración de la base de datos (herramientas para mantener la seguridad de
los datos, herramientas de recuperación, etc.).
• Mantener la integridad de los datos.
• Permitir la concurrencia en el acceso a los datos.
• Definir el diccionario de datos.
Un buen SGBD tiene que:
• Permitir describir los distintos esquemas de la base de datos, los aspectos importantes de
los datos y sus relaciones.
• Mantener la independencia entre los diferentes niveles, por ejemplo de los datos frente a
su representación física.
• Permitir establecer la correspondencia entre los esquemas y los datos en cada esquema.
• Aislar los esquemas entre sí de forma que las modificaciones en uno no afecten a los
demás (independencia de datos).
Los componentes de un SGBD son:
• Lenguajes de definición del esquema lógico, interno y externo (en la práctica no existen
herramientas de definición del esquema conceptual independiente del SGBD, por lo que se
añade un esquema lógico dependiente del SGBD intermedio entre el esquema conceptual
y el interno).
• Lenguajes de manipulación de la base de datos.
• Utilidades, entre las que destacan las generadoras de copias de seguridad, reconstrucción
de bases de datos dañadas, obtención de estadísticas, etc.
• Lenguajes de programación de alto nivel para el manejo de la base de datos.
Figura 2: Independencia entre los esquemas en los SGBD
3. El modelo relacional
3.1. Los modelos de datos y el modelo relacional
Utilizamos los modelos de datos para representar una abstracción de la parte del mundo real que
queremos plasmar en el sistema de información. Con ellos debemos representar las propiedades
estáticas (objetos, relaciones y restricciones) como las dinámicas (operaciones sobre los objetos,
transacciones, restricción en la evolución de los objetos y sus relaciones).
Entre los distintos modelos que se han utilizado, podemos destacar los modelos jerárquicos
(estructurados en árbol), en red (CODASYL), relacionales, orientados a objetos, etc.
El modelo relacional fue presentado por E. Codd en 1970 y aún hoy sigue vigente, es el modelo de
datos de más éxito entre los SGBD y en el que se basan muchos de los grandes sistemas
comerciales (Oracle, SQL Server, Informix, DB2, MySQL, PostgreSQL, etc.). De manera informal
en un sistema relacional los datos son percibidos por el usuario como tablas y los operadores de
recuperación de esos datos generan nuevas tablas a partir de las anteriores. Al mismo tiempo,
Codd también propuso tres lenguajes de definición y manipulación de datos basados en el Álgebra
de conjuntos y en el Cálculo de Predicados de Primer Orden.
Una de las principales ventajas y razones del éxito del modelo es su lenguaje de consulta, el SQL
(Structured Query Language) que será estudiado con mayor profundidad en los siguientes
apartados.
3.2. Estructuras del modelo relacional
La estructura de datos relación es la estructura fundamental del modelo, como su nombre indica.
Relación es el término matemático para la tabla. Representa tanto los objetos como las relaciones
entre ellos. Viene definida por un conjunto de nombres de atributos, cada uno de los cuales tiene
asociado un dominio. Una o más relaciones forman el esquema de una base de datos relacional.
La forma más cómoda de representar las relaciones es mediante tablas. Veamos unos ejemplos:
Tabla I: Relación Clientes
Código Nombre Dir Teléfono

1 Juan Pérez Mayor, 10 999999999
2 Frutas Fresa Enmedio, 21 666666666
3 Automóviles AJ Nueva, 3 777777777
Tabla II: Relación Facturas
Código Cod_Cliente Fecha

2015-102 1 10/12/2015
2016-1 2 05/01/2016
2016-2 3 07/01/2016
Tabla III: Relación Productos
Código Nombre Precio

1 Hora de análisis 50
2 Hora de desarrollo 40
3 Hora de consultoría 50
Tabla IV: Relación Líneas de factura
Cod_Factura Num_Línea Cod_Producto Cantidad

1 1 1 3
1 2 3 3
2 1 2 10
3 1 2 10
Formalmente una relación de esquema R {(A1,D1),(A2,D2),(A3,D3),…,(An,Dn)} es un conjunto de

tuplas {(A1,V1),(A2,V2),(A3,V3),…,(An,Vn)} tales que V1 Є D1, V2 Є D2, V3 Є D3, …,Vn Є Dn.
El grado de una relación es el número de atributos de su esquema (informalmente corresponde al

número de columnas de la tabla) y la cardinalidad es su número de tuplas (informalmente el
número de filas). Un dominio en el modelo relacional equivale a un tipo de datos, no tiene
estructura, y es la unidad semántica de datos más pequeña.
Volviendo al ejemplo anterior, la relación Clientes la representaremos de la siguiente forma:
Clientes (codigo:dom_codigo, nombre:dom_nombre, dir:dom_dir, telefono:dom_telefono)
Y una ocurrencia de la relación:
Clientes={ { (Codigo,1), (Nombre,Juan Pérez), (Dir, Mayor, 10), (Telefono, 999999999) }
{ (Codigo,2), (Nombre,Frutas Fresa), (Dir, Enmedio, 21), (Telefono, 666666666) }
{ (Codigo,3), (Nombre,Automóviles AJ), (Dir, Nueva, 3), (Telefono, 777777777) }
Una forma habitual de representar la vida real mediante el modelo relacional es utilizar diagramas
Entidad-Relación, que se estudiarán en detalle en el Tema 44. Como adelanto, la relación Clientes
del ejemplo se representaría como una entidad con sus atributos.
Figura 3: Entidad-Relación
3.3. Restricciones en el modelo relacional
El modelo relacional permite representar la vida real, como se ha comentado anteriormente, pero
con lo estudiado hasta ahora, permitiría la existencia de ocurrencias no válidas en la vida real. En
el ejemplo anterior podría existir una tupla con el código repetido o sin nombre en el cliente. Las
restricciones son las herramientas que nos permiten definir qué cosas queremos que nuestro
modelo no permita.
Restricción de valor no nulo. Se aplica sobre un atributo, dicho atributo no puede tener valor nulo
para ninguna tupla de la relación.
Restricciones de unicidad.
• Clave candidata. Conjunto de uno o más atributos que identifican de forma única la tupla y
no existe un subconjunto de esos atributos que también identifiquen de forma única la
tupla. Dicho de otra forma, no se puede repetir otra tupla con los mismos valores en el
conjunto de atributos que forman la clave candidata.
• Clave primaria y alternativa. Si existe más de una clave candidata en una entidad, una u
solo una de ellas es la clave primaria. El resto de denominan claves candidatas. La clave
primaria servirá para referenciar las tuplas de la relación.
La integridad de clave primaria es exactamente el cumplimiento de la restricción de unicidad de la

clave primaria y la ausencia de valores nulos.
Restricciones sobre entidades y relaciones entre entidades.
• Clave ajena. La clave ajena es el mecanismo del modelo relacional para establecer las
relaciones entre entidades. Dada una entidad R {(A1,D1),(A2,D2),(A3,D3),…,(An,Dn)} y S
{(B1,E1),(B2,E2),(B3,E3),…,(Bn,En)} y sea CPS la clave primaria de S, la clave ajena de R
que referencia a S :
• Un subconjunto de atributos de R CARS={Ai,Aj,…,Ak} y
• Una biyección f:CARS → CPS tal que cualquier elemento Ai de CARS se cumple que Ai y
el atributo de CPS asociado f(Ai) tienen el mismo dominio.
Se cumple que para toda tupla de R existe una tupla de S tal que los atributos Ai de la tupla en R
son iguales en la tupla en S o la tupla en R tiene valor nulo en esos atributos.
Figura 4: Clave ajena
Dicho de otra manera, la clave ajena es uno o más atributos de una relación R cuyo valor es nulo o
coincide con la clave primaria de otra relación S.
3.4. Operadores en el modelo relacional
Los operadores son los lenguajes relacionales, lenguajes de especificación mediante los cuales se
expresa lo que se quiere obtener de la base de datos, o las operaciones que se quieren realizar,
sin especificar cómo tiene que ser obtenida dicha información.
Existen dos notaciones para expresar las operaciones sobre las relaciones, notación algebraica o
álgebra relacional y notación lógica o cálculo relacional (de tuplas y de dominios). En total tres
lenguajes equivalentes entre sí con un objetivo fundamental, la expresión de consultas a la base
de datos.
3.4.1. Álgebra relacional. Operadores
Para el álgebra relacional se definen ocho operadores:
• Unión (U). R U S será la unión de todas las tuplas que están en R y todas las tuplas que
están en S. Las relaciones tiene que ser compatibles, es decir, tienen el mismo esquema
relacional. El resultado también será compatible.
• Intersección (∩). R ∩ S serán las tuplas que están en R y en S. R y S serán compatibles,

así como el resultado de la intersección.
• Diferencia (-). R – S serán las tuplas que están en R y no en S. R y S serán compatibles,

así como el resultado de la diferencia.
• Producto cartesiano (x). R x S será la combinación de todas las tuplas de R con cada una
de las tuplas de S. Los atributos del producto cartesiano serán los atributos de R más los
atributos de S.
• Selección (donde). S donde condicion selecciona las tuplas de S que cumplen la condición
condicion. Los atributos de la selección son los mismos de S.
• Proyección ([]). La relación resultante contiene las mismas tuplas que la original, pero
únicamente los atributos indicados en el operador.
• Concatenación (∞). R ∞ S es la combinación de todas las tuplas de R y S cuyos valores

coincidan en una serie de atributos comunes. La relación resultante tendrá todos los
atributos de R y todos los de S no comunes con R.
• División (÷). R ÷ S son las tuplas R que están combinadas con todas las tuplas de S. La
relación resultante son los atributos no comunes de R.
Los cuatro primeros son operadores conjuntistas, similares a los utilizados en la teoría de
conjuntos. Los cuatro últimos son propiamente relacionales. El resultado de cualquier operación
relacional es otra relación, lo que permite el anidamiento de operaciones.
Algunos ejemplos de consultas en álgebra relacional y su correspondiente en SQL, que se

estudiará más adelante, pero resultará útil empezar a familiarizarse con él:
Selección. Clientes cuyo teléfono sea 666666666.
Clientes donde telefono=’666666666’
select * from Clientes where telefono=’666666666’
Proyección. Los nombres de los clientes.
Clientes [nombre]
select nombre from Clientes
Producto cartesiano. Combinación de clientes y productos.
Clientes x Productos
select * from Clientes, Productos
Concatenación. Clientes y sus facturas.
Clientes ∞ Facturas
select * from Clientes, Facturas where clientes.codigo=facturas.cod_cliente
Concatenación. Nombres de clientes y sus números de factura.
Clientes [Nombre] ∞ Facturas [Código]
select Clientes.nombre, Facturas.codigo from Clientes, Facturas where

clientes.codigo=facturas.cod_cliente
Se observa que el operador concatenación lleva implícita la condición que debe cumplirse, en este
caso que el código de cliente de la relación Facturas corresponda al código de cliente de la
relación Clientes. En lenguaje SQL, la condición se debe indicar explícitamente.
3.4.2. Cálculo relacional de tuplas y dominios
El cálculo relacional se basa en el cálculo de predicados de la lógica matemática. Se basa en el

uso de variables-tupla, símbolos de constante, nombres de relación, operadores de comparación,
predicado de comprobación de valor nulo, nombres de atributo, conectivas lógicas (negación ¬ ,
conjunción ∧ , disyunción ∨ , implicación → ) y cuantificadores ( ∃ , ∀ ). Con estos símbolos
formamos condiciones y fórmulas bien formadas. Sin entrar en detalles, las sentencias del cálculo
relacional de tuplas tienen su equivalente en el álgebra relacional, y viceversa. Unos ejemplos del
cálculo relacional de tuplas servirán de ilustración:
Nombres de los clientes cuyo teléfono sea 666666666.
X: Cliente
Cliente(X) ∧ X.telefono=’666666666’
Nombre de los clientes con alguna factura.
X: Cliente
Y: Factura
Cliente (X) ∧ ∃ Y (Factura(Y) ∧ X.codigo=Y.cod_cliente)
La diferencia fundamental entre el cálculo relacional de tuplas y el cálculo relacional de dominios

consiste en que el segundo utiliza variables definidas sobre el dominio de alguno de los atributos
del esquema (variables-dominio) en lugar de las variables-tupla del primero. En los ejemplos
anteriores:
X:dom_nombre Y:dom_telefono
∃ X(Cliente(codigo:X,telefono:Y) ∧ Y=’666666666’)
X:dom_codigo Y:dom_nombre Z:dom_cod_cliente
∃ X(Cliente(codigo:X,nombre:Y) ∧ ∃ Z(Factura(cod_cliente:Z) ∧ Z=X ))
4. El lenguaje SQL
El lenguaje SQL es el estándar para trabajar con bases de datos relacionales. Fue desarrollado por
IBM en los años 70, pero su versión más estándar y utilizada fue SQL/92, aceptada y asumida por
muchos fabricantes con muy pocas modificaciones. Incluye operaciones de definición de datos
(DDL) y de manipulación (DML). Aunque no es un lenguaje que cumpla todos los requisitos del
modelo relacional, su amplia difusión hace que su conocimiento y dominio sea necesario para
cualquier profesional que maneje como parte de su trabajo bases de datos relacionales.
Versiones posteriores de SQL añadieron funcionalidades al estándar, como SQL/99 (triggers y

soporte para expresiones regulares) o SQL/2005 (soporte XML) entre otras.
Es importante destacar que SQL es un estándar, pero no tiene por qué estar completamente
implementado en todos los gestores, de igual forma que algunos gestores incorporan instrucciones
a su SQL que no forman parte de estándar. El manejo de cadenas o de tipos de datos de fecha y
hora puede cambiar de unos gestores a otros, e incluso de unas versiones a otras dentro del
mismo sistema, por lo que es necesario conocer el sistema destino a la hora de escribir sentencias
SQL.
4.1. Instrucciones básicas
Para la definición de datos, la sentencia más importante el CREATE TABLE, el siguiente ejemplo
crearía las tablas clientes y productos del ejemplo anterior en lenguaje SQL/92, crearía las
restricciones de integridad de clave primaria de las tablas y la restricción de clave ajena de la tabla
de productos a la de tipos de producto.
Create table clientes
(numero_cli numeric(5),
nombre_cli char (100),
compras_anyo numeric (10,2),
primary key (numero_cli));
Create table tipo_producto
(cod_tipo char(15),
nombre_tipo char (100),
primary key (cod_tipo));
Create table productos
(cod_pro char(15),
nombre_pro char (100),
precio_coste_pro numeric (10,2),
precio_venta_pro numeric (10,2),
precio_coste_pro numeric (10,2),
ins_produccion char(100),
tipo_producto char(15),
primary key (cod_pro),
foreign key (tipo_producto) references tipo_producto );
Para la manipulación de datos, las sentencias más comunes son SELECT (consultar a la base de
datos), INSERT (instrucciones de inserción de uno o varios registros en una tabla), UPDATE
(modificación de algún registro de una tabla) y DELETE (borrado de algún registro de una tabla).
Dentro de éstas podemos utilizar operaciones para proyectar, restringir y juntar. Por ejemplo la
siguiente sentencia une las tablas productos y tipo_producto, restringiendo los productos con un
precio de coste mayor a 100 y proyectando alguna de sus columnas:
SELECT cod_pro, nombre_pro, precio_coste, nombre_tipo --proyectar
FROM productos, tipo_producto --juntar, join
WHERE precio_coste>100 --restringir
and productos.tipo_producto=tipo_producto.cod_tipo --condicion join
Para insertar un registro en una tabla de la base de datos, utilizamos el operador INSERT. En el
siguiente ejemplo insertamos en la tabla de productos un registro con código ‘A001’, nombre 'Hora
de desarrollo' y precio de venta 30. No se han indicado valores para el resto de columnas de la
tabla, lo que las dejará a NULO o a sus valores por defecto si los tuvieran. En caso de que alguna
de esas columnas tuviera una restricción de no nulo, la sentencia daría un error de ejecución al
incumplir las restricciones definidas:
INSERT into productos (cod_pro, nombre_pro, precio_venta_pro)
VALUES ('A001','Hora de desarrollo',30)
Para modificar uno o varios registros de una tabla utilizamos el operador UPDATE. En el siguiente
ejemplo se incrementará el precio de todos los productos que cumplan una condición. Dicha
condición está implementada a su vez como una consulta a otra tabla de la base de datos. Estos
anidamientos nos permitirán construir sentencias SQL tan complejas como sea necesario.
UPDATE productos SET precio_venta_pro=precio_venta_pro*1.2
WHERE tipo_producto in (
SELECT cod_tipo FROM tipo_producto
WHERE nombre_tipo='Desarrollo' or nombre_tipo='Consultoría')
Para eliminar registros de una tabla utilizamos el operador DELETE. El siguiente ejemplo borrará
todos los registros de la tabla de tipos de producto:
DELETE FROM tipo_producto
La instrucción anterior dará error de ejecución si alguno de los tipos de producto ha sido
referenciado en la tabla de productos, ya que su eliminación rompería la integridad de la base de
datos definida por restricción de clave ajena de productos a tipos de producto (foreign key
(tipo_producto) references tipo_producto en la sentencia de creación de la tabla de productos).
Para eliminar uno o algunos de los registros de una tabla, podemos incluir una condición de la
siguiente manera:
WHERE tipo_producto='A002'
O utilizando una sentencia SELECT dentro de la condición, se pueden eliminar los tipos de
producto que no han sido referenciados en ningún registro de la tabla de productos:
WHERE cod_tipo not in (
SELECT tipo_producto
FROM productos)
4.2. Vistas
Las vistas son consultas a la base de datos que se utilizan frecuentemente. No son tablas,
únicamente consultas sobre tablas, pero en el caso de dispongan de los permisos pertinentes,
pueden ser utilizadas tanto para consultar como para insertar o borrar.
Una vez creada una vista, ésta puede ser utilizada en los mismos contextos que una tabla.
Podemos crear una vista con información de los productos desde el punto de vista de producción
con la siguiente sentencia:
CREATE VIEW productos_produccion (codigo, nombre, instrucciones)
AS select cod_pro, nombre_pro, ins_produccion
from productos
También podemos utilizarlas para filtrar la información, por ejemplo:
CREATE VIEW productos_consultoria (codigo, nombre, precio_venta)
AS select cod_pro, nombre_pro, precio_venta_pro
from productos
where tipo_producto='A001'
O para unir información de más de una tabla:
CREATE VIEW productos_con_tipo (codigo, nombre, cod_tipo, nombre_tipo)
AS select productos.cod_pro, productos.nombre_pro, tipo_producto.cod_tipo,

tipo_producto.nombre_tipo
from productos, tipo_producto
where productos.tipo_producto=tipo_producto.cod_tipo
Las vistas son un mecanismo que puede ayudar a mantener la independencia lógica, ya que añadir
un nuevo atributo en una tabla no afectaría a las vistas que actúan sobre ella. También permite
mostrar distinta información a distintos usuarios y pueden ser un mecanismo de ayuda a mantener
la seguridad de los datos, ocultando algunos atributos o incluso algunos registros.
4.3. Triggers y procedimientos almacenados
Los sistemas de gestión de bases de datos pueden implementar procedimientos, programas,

disponibles para el usuario y ejecutados directamente por el gestor, lo que los hace especialmente
eficientes. Los usos más habituales son para mantener la integridad lógica de los datos y para
encapsular tareas complejas, que pueden involucrar más de una tabla de la base de datos.
Los triggers o disparadores son procesos que se ejecutan automáticamente después de hacer una
operación en la base de datos. Por ejemplo:
CREATE TRIGGER ins_productos
ON productos
AFTER INSERT
execute pr_ins_pruductos (cod_pro)
Cada vez que se inserte un registro en la tabla de productos, el sistema llamará al procedimiento
almacenado pr_ins_productos pasándole el código del producto recién creado. El procedimiento
podría hacer algún tipo de comprobación o insertar un registro en una tabla de auditoría donde se
incluyera información del momento en el que se ha creado el producto, por ejemplo.
Definiendo un disparador en el borrado de una tabla, podríamos hacer que se guardaran los datos
del registro a borrar en otra tabla de registros eliminados, de forma que pudieran ser recuperados
en caso de necesidad.
CREATE PROCEDURE pr_del_clientes (numero_cli, nombre_cli, compras_anyo)
BEGIN
INSERT INTO clientes_borrados (numero_cli, nombre_cli, compras_anyo)
END
CREATE TRIGGER del_clientes
ON clientes
AFTER DELETE
execute pr_del_clientes (numero_cli, nombre_cli, compras_anyo)
La sintaxis de los triggers y procedimientos almacenados no siempre es compatible entre los

distintos sistemas de gestión relacionales. La sintaxis utilizada en los ejemplos anteriores, con
fines didácticos, trata de mostrar las posibilidades que nos ofrecen estas herramientas sin
corresponder con ninguna sintaxis real implementada en un sistema o en el estándar SQL.
5. Bases de datos no relacionales
Aunque el modelo relacional sigue siendo un modelo válido para muchos de los sistemas de
información actuales tales como el tratamiento de datos alfanuméricos o los sistemas de gestión
empresarial, por poner algún ejemplo, la evolución de los sistemas de información ha hecho que en
algunos casos el modelo no sea válido. Así se han ido desarrollando nuevos modelos de bases de
datos y sus respectivos sistemas de gestión. En los siguientes apartados se estudiarán algunos de
ellos.
5.1. Bases de datos orientadas a objetos y objeto-relacionales
Durante muchos años los modelos relacionales han predominado como sistemas de bases de
datos necesarios para los sistemas de información tradicionales de gestión de las empresas y los
negocios. Pero estos modelos no son los más adecuados cuando los sistemas necesitan
almacenar y tratar documentos, imágenes, vídeos, etc. (multimedia) o con la aparición los sistemas
de fabricación asistidos por ordenador (CAD/CAM), las bases de datos gráficas, los sistemas de
información geográfica, etc. Las nuevas aplicaciones necesitan estructuras más complejas para
almacenar los datos, transacciones más grandes, tipos de datos para almacenar imágenes,
grandes bloques de texto, etc. También operaciones que manejen esos datos. Una primera
solución planteada para ese problema fueron las bases de datos orientadas a objetos.
Muchos fabricantes de sistemas de gestión de bases de datos tradicionales (relacionales) han

añadido funcionalidades de orientación a objetos, dando lugar a las bases de datos objeto-
relacionales. Incluso revisiones más modernas del estándar SQL han incluido algunas de esas
características.
5.1.1. Bases de datos orientadas a objetos
En el modelo de datos de las bases de datos orientadas a objetos cada elemento es un objeto con
identidad única, propiedades y comportamiento. Conceptos de la orientación a objetos llevados a
las bases de datos. Las tuplas del mundo relacional se sustituyen por objetos.
La identidad única no equivale a la clave primaria, sino que es un identificador generado por el
sistema, no modificable y oculto al usuario. El valor del objeto se expresa mediante sus
propiedades, que se almacenan en una estructura de datos que puede ser tan compleja como sea
necesario. Las operaciones que manipulen los valores también tendrán que ser proporcionados por
el sistema.
Se definen constructores para los tipos de objetos utilizando constructores básicos (enteros,
cadenas, etc.) y pueden ser anidados creando estructuras más complejas.
También se definen referencias entre objetos cuando un atributo se define como referencia a otro
tipo de objeto. La integridad referencial de los sistemas relacionales es aquí más fácil de
implementar.
Los objetos tienen un estado que se corresponde con el valor que tiene asignado el objeto en un
momento dado. Las operaciones sobre un objeto tienen que estar previamente implementadas, así
como la comunicación entre objetos, asegurando de esta manera el encapsulamiento.
Distinguimos la signatura (parte pública de la operación) del método (procedimiento implementado
en algún lenguaje de programación y oculto al usuario). Así pues la única forma de acceder a un
atributo de un objeto es desarrollar una operación que lo consulte y devuelva como salida su valor.
Las bases de datos orientadas a objetos permiten a nivel de diseño métodos de abstracción
similares a las relacionales, además de otros métodos específicos, como agregación, asociación,
generalización y especialización, herencia, polimorfismo. También se han propuesto lenguajes de
consulta similares a SQL como el OQL (Object Query Language).
Algunos de los sistemas de gestión de bases de datos orientadas a objetos son O2 y ObjectStore.
Tabla V: Ventajas e inconvenientes de las bases de datos orientadas a objetos

Ventajas Inconvenientes
Mejor integrados con los lenguajes orientados Aunque tiene mayor capacidad de consulta,
a objetos éstas son más complejas
Mejor representación y tratamiento de los Pérdida de la generalidad de las bases de

datos datos relacionales
Acerca el modelo conceptual al modelo lógico No existe una implementación estándar. Cada
fabricante lo ha implementado a su manera
Mejora en las capacidades de consulta a la
base de datos
5.1.2. Bases de datos objeto-relacionales
Los sistemas de gestión de bases de datos relacionales han ido adaptándose a las nuevas
necesidades de los sistemas de información añadiendo las características propias de la orientación
a objetos, al mismo tiempo que han aparecido nuevos sistemas con estas características ya
implementadas, dando lugar a los sistemas de gestión de bases de datos objeto-relacionales.
Estos sistemas, a diferencia de los orientados a objetos recién estudiados, cumplen con los dos
modelos, tanto el relacional como el orientado a objetos.
Este enfoque permite a los usuarios utilizar la orientación a objetos, definir sus propios tipos de
datos, asociar métodos y constructores, aunque internamente los datos sigan siendo almacenados
en tablas.
SQL:1999 propone un modelo de objetos que enriquece el modelo relacional con la posibilidad de
definir tipos de datos estructurados con interfaz de métodos y asignar (o no) un tipo a una tabla.
Una tabla sin tipo asociado es una tabla relacional tradicional, una tabla con tipo es una tabla
cuyas filas son instancias del tipo de datos correspondiente.
Así pues la principal diferencia entre los sistemas de gestión de bases de datos orientadas a
objetos y los objeto-relacionales es que los primeros se desarrollan según el paradigma de la
orientación a objetos y los segundos son sistemas relacionales que han evolucionado hasta
sistemas que soportan las dos tecnologías, la relacional y la orientación a objetos.
Podemos asumir que las ventajas e inconvenientes de los sistemas objeto-relacionales son
similares a las de los sistemas orientados a objetos, con la diferencia de que los objeto-
relacionales son compatibles con los relacionales. Un sistema puede mantener sus bases de datos
relacionales, al ser éstas un subconjunto de las que puede mantener un sistema objeto-relacional.
Además, admiten el lenguaje SQL, aunque con alguna diferencia.
6. Bases de datos no estructuradas. NoSQL
Las bases de datos NoSQL (Not Only SQL, no solo SQL) aparecen también para resolver la
gestión de los datos donde las bases de datos tradicionales (relacionales) no alcanzan. Cuando los
sistemas a implementar necesitan de una gran flexibilidad en los datos, los sistemas relacionales,
con su estructura bien definida, no son la mejor opción. Tampoco cuando las bases de datos tienen
altos niveles de distribución, requisitos muy estrictos de rendimiento en consulta o grandes
volúmenes de datos.
Aplicaciones como Facebook, Instagram, FourSquare, Twitter, etc. son las pioneras en el uso de
estas bases de datos. Que cualquier usuario pueda incluir información en sus bases de datos
provocó que el volumen creciera exponencialmente, haciendo desaconsejable el uso de sistemas
tradicionales.
También es útil este tipo de bases de datos en entornos de desarrollo ágil, con frecuentes
modificaciones en el modelo de datos. Situaciones en las que el modelo relacional puede hacer
que las iteraciones no sean tan ágiles como se espera.
Según el modelo de datos, las bases de datos NoSQL pueden dividirse en:
Clave-valor
Los elementos se identifican por una clave única y almacenan el resto de información en un campo
BLOB o similar, haciendo la recuperación de información muy rápida. Algunos ejemplos son
Cassandra (Facebook, Twitter) o BigTable (Google).
Documentales
También utilizan una clave única para cada elemento, pero almacenan la información en una
estructura tipo JSON o XML, lo que le permite una estructura dinámica. Permite búsquedas más
complejas que el Clave-valor. Una estructura que en el mundo relacional podría consistir en varias
tablas y columnas relacionadas por claves ajenas, aquí se almacena como un único registro o
documento. Dos documentos de la mista “tabla” pueden o no tener la misma estructura. MongoDB
(FourSquare, Ebay) o Firebase Realtime Database (adquirida por Google) utilizan esta estructura.
En grafo
La información se representa como nodos de un grafo y las relaciones son las aristas del grafo.
Necesita de una estructura fija para proporcionar un buen rendimiento. Algunos ejemplos son
Neo4j (Infojobs) o Infogrid.
Orientadas a objetos
Aunque se estudiaron en el apartado anterior, son un ejemplo de bases de datos no solo SQL.
6.1. Ventajas de las bases de datos NoSQL
Entre las ventajas de adoptar un sistema de base de datos NoSQL destacan:
• Pueden utilizarse máquinas con pocos recursos.
• Tiene una buena escalabilidad horizontal. Añadir más servidores mejorará el rendimiento
del sistema de forma óptima.
• Proporcionan un alto rendimiento.
• Pueden manejar grandes cantidades de datos.
• No hay cuellos de botella en la gestión de las peticiones, por los pocos recursos que
requieren.
• Permite estructuras de datos dinámicas.
• Permite una arquitectura distribuida.
6.2. Inconvenientes de las bases de datos NoSQL
Los inconvenientes de estos sistemas frente a los tradicionales son:
• No utilizan SQL como lenguaje de consulta.
• No existe un estándar de modificación de la base de datos. Cada sistema ha implementado

el suyo.
• No están suficientemente maduros.
• Según la implementación, estos sistemas no pueden asegurar la consistencia en los datos

que sí asegura el modelo relacional.
• El análisis de datos (Bussiness Intelligence) es más complicado que en los sistemas

tradicionales.
(1) Date, C.J. (2001). Introducción a los sistemas de bases de datos. Prentice Hall / Addison
Wesley Iberoamericana
(3) ANSI/X3/SPARC Study Group on Data Base Management Systems: (1975), Interim Report.
FDT, ACM SIGMOD bulletin. Volume 7, No. 2.
(4) Mota, L., Celma, M., Casamayor, J.C., (1994) Bases de datos relacionales: Teoría y diseño.
Universidad Politécnica de Valencia
(5) Silberschatz, S., Korth, H. (2002) Fundamentos de bases de datos. Mcraw-Hill
(6) de Miguel, A., Piattini, M. (1993) Concepción y diseño de bases de datos. RA-MA
(7) http://aws.amazon.com
(8) Acens whitepapers. https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-

acens.pdf. Bases de datos NoSQL. Qué son y qué tipos nos podemos encontrar
(9) MongoDB. https://www.mongodb.com/nosql-explained. NoSQL databases explained
Tema 29. Tecnologías para el desarrollo de
aplicaciones. Microsoft.NET, JAVA, PHP.
Frameworks de desarrollo
Antonio Campos Serna

Colegiado 0920
En el siguiente tema se expone, de manera muy resumida, las principales tecnologías

y lenguajes para el desarrollo de aplicaciones web.
Java, PHP y MS.NET son, por su utilización tan extendida, los lenguajes de
programación más importantes hoy por hoy. Con ellos se escribe el 30% de todo el
código generado en el mundo y el 99% si nos referimos exclusivamente a los
lenguajes web “del lado del servidor” (datos referentes a septiembre de 2.016
obtenidos de tiobe.com y w3techs.com).
Java fue desarrollado desde 1.991 por un equipo de Sun Microsystems liderado por
James Gosling. La primera versión de Java fue publicada en enero de 1.996. En 2.007
Sun Microsystems empezó a distribuir Java bajo los términos de la licencia GNU-GPL
(http://www.gnu.org/licenses/gpl.html). En 2.009 Sun Microsystems fue adquirida por
Oracle y desde entonces se ha mantenido una posición ambigua respecto a la licencia
de distribución de Java. En 2.010 James Gosling abandonó Oracle
PHP fue desarrollado en 1.994 por Rasmus Lerdof como un conjunto de herramientas
para un proyecto personal. En 1.997 Zeev Suraski y Andi Gutsman retomaron el
desarrollo y en 1.998 publicaron PHP 3. En 1.999 fundan la empresa Zend
Technologies que desde entonces es la encargada de desarrollar el lenguaje y lo
distribuye bajo la licencia PHP License (http://www.php.net/license/3_01.txt).
Micorsoft comenzó el desarrollo de .NET (punto NET) en la segunda mitad de los 90’s
y la primera versión estable se lanzó en febrero de 2.002. El lanzamiento de .NET
puede considerarse como la alternativa de Microsoft para el mercado del desarrollo
web, y en cierta medida una respuesta a Java.
1. MS.NET
1.1. Introducción
Microsoft .NET es un conjunto de tecnologías y herramientas que proporcionan un entorno de

ejecución que facilita diversos servicios a las aplicaciones en ejecución. Sus componentes
principales:
• Common Language Runtime (CLR): es el motor que controla las aplicaciones en ejecución.
• Biblioteca de clases: proporciona una biblioteca de código probado y reutilizable.
• ASP.NET: añade funcionalidad a las aplicaciones web.
• Windows Forms: herramientas para el desarrollo de aplicaciones de escritorio.
Figura 1: Entorno Microsoft.NET
Los principales servicios que provee Microsoft .NET a las aplicaciones son:
• Administración de la memoria: en las aplicaciones de .NET, CLR proporciona este servicio.
• Interoperabilidad de lenguajes: el compilador genera un código intermedio denominado

Common Intermediate Language (CIL). Es similar a los bytecodes de Java y se compila en
tiempo de ejecución a través de Common Language Runtime.
• Ejecución en paralelo: se permite que varias versiones de Common Language Runtime

coexistan en el mismo equipo. Esto significa que también pueden coexistir varias versiones
de las aplicaciones, y que una aplicación se puede ejecutar en la versión de .NET
Framework con la que se compiló.
Tecnologías para el desarrollo de aplicaciones. MS.NET, JAVA y PHP
1.2. Common Language Runtime
El Common Language Runtime (CLR) es el núcleo de la plataforma .NET, es el encargado de la

gestión y ejecución de las aplicaciones.
Como se ha comentado anteriormente, las aplicaciones .NET cuando se compilan generan un

código intermedio (CIL) que es de nuevo compilado en tiempo de ejecución para generar el
ejecutable definitivo en código nativo de la máquina donde se va a ejecutar. El funcionamiento es
similar al de Java, bytecodes y la JVM, pero a diferencia de la JVM que interpreta los bytecodes, la
CLR compila el CIL a código nativo de la máquina donde se va a ejecutar.
Figura 2: Proceso de compilación en .NET
Los principales servicios que incorpora el CLR son:
• Integración de lenguajes: permite integrar códigos fuentes escritos en distintos lenguajes.
• Gestión de memoria: es el responsable de eliminar los objetos que ya no están en uso

liberando de esta manera la memoria.
1.2.1. Common Intermediate Language
Todos los compiladores incluidos en la plataforma .NET generan código intermedio CIL, este es el
único lenguaje que “entiende” la CLR.
El CIL facilita la integración en una misma aplicación de distintos lenguajes de programación.

También permite que las aplicaciones sean multiplataforma al ser independiente de la
especificación hardware de la máquina en la que se va a ejecutar la aplicación.
El módulo encargado de generar el código nativo que se va a ejecutar a partir del código CIL se
llama compilador JIT (Just-In-Time), y está integrado en la CLR. JIT va compilando dinámicamente
el código CIL a medida que va a ser ejecutado.
1.2.2. Common Type System (CTS)
Todos los compiladores de la plataforma .NET unifican los tipos de datos de cada uno de los
lenguajes al Sistema de Tipos Común (CTS) que puede ser considerado como un sistema de tipos
de datos independiente del lenguaje de programación. De esta manera, los datos del código
intermedio CIL, son los únicos que admite la CLR.
Figura 3: Tipos definidos en CTS
Los tipos de datos por referencia siempre se gestionan con direcciones de memoria, tanto para la
asignación como para la comparación.
1.3. Biblioteca de clases
La plataforma .NET incorpora una librería de clases (Framework Class Library) formada por cientos
de clases que facilitan la interacción del programador con los servicios ofrecidos por la CLR.
Esta librería está escrita en CIL, lo que permite que sea usada por cualquier lenguaje de la
plataforma .NET (C#, VB.NET,…).
Todas las clases que incluye la FCL están organizadas en espacios de nombre (similares a los
packages de Java) cuya raíz es System. Los espacios de nombres mas usados son:
• System: contiene los tipos de datos básicos, tablas, excepciones,…
• System.Object: Soporta la jerarquía de clases de .NET.
• System.Collections: Colecciones de datos (listas, pilas, colas, …).
• System.Data: Incluye las clases para el acceso a Base de Datos mediante la arquitectura
ADO.NET.
• System.IO: Gestión de ficheros.
• System.Math: funciones matemáticas.
• System.XML: Gestión de estructuras de datos en formato XML.
1.4. Windows Forms
Es la herramienta de .NET para crear aplicaciones avanzadas de escritorio. Se utiliza para diseñar
y programar los formularios (WinForms o ventanas) con los que el usuario interactuará con la
aplicación.
Las clases que se utilizan descienden directamente de las Windows Foundation Classes (WFC) y
su espacio de nombres es System.Windows.Forms.
1.5. ASP.NET
Es el modelo de desarrollo para web que introduce .NET, puede decirse que es la extensión del
lenguaje ASP para la plataforma .NET, incluyendo los servicios de la CLR y la FCL. El código de
las aplicaciones puede escribirse en cualquier lenguaje que soporte la Common Language
Runtime.
Una de las características principales de ASP.NET es que permite trabajar con elementos HTML
en la propia página, por lo que la diferenciación de código a ejecutar en el servidor o en el cliente
se difumina, ya que todo está incluido en el mismo código. Incluye diseño de controles específicos
para programar aplicaciones que se ejecutan sobre dispositivos móviles.
En cuanto a la capa de presentación, ASP.NET permite controlar la apariencia general de los sitios
web a través de la definición de temas y máscaras que pueden aplicarse tanto a las páginas como
los controles.
Respecto a la seguridad, ASP.NET permite identificar usuarios con la autenticación de Windows

que incluye Internet Information Server. También permite gestionar el acceso a los recursos
(ficheros, bases de datos, …) de la aplicación web mediante los grupos de Windows.
ASP.NET permite almacenar el estado de la página de manera que, entre cada una de las
llamadas desde el cliente, se pueda compartir información. Puede guardar y administrar
información específica de la aplicación, de la sesión, de la página y del usuario.
1.5.1. Hola Mundo en ASP.NET
<%
lblHolaMundo.Text = "Hola mundo";
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Hola Mundo</title>
</head>
<body>
<form id="formHolaMundo" runat="server">
<div>
<asp:Label runat="server" id="lblHolaMundo"></asp:Label>
</div>
</form>
</body>
</html>
1.6. C# (C Sharp)
Es un lenguaje de programación orientado a objetos que forma parte de la plataforma .NET. C# es

un lenguaje multipropósito con el que pueden desarrollarse aplicaciones de escritorio, servicios
web, componentes distribuidos, aplicaciones cliente-servidor, aplicaciones de bases de datos, etc.
La sintaxis de C# es muy similar a la de los lenguajes C, C++ y Java pero con características
propias como tipos de datos que admiten el valor NULL, enumeraciones, delegados y acceso
directo a memoria (que no incluye Java). También admite la definición de métodos genéricos
(funciones donde tanto los parámetros de entrada como el tipo devuelto admiten cualquier tipo de
dato).
C# incluye todas las características de la POO (encapsulación, herencia y polimorfismo). También

soporta interfaces y al igual que en Java, en C# una clase subclase sólo puede heredar de una
única superclase pero puede implementar varias interfaces. Además de las clases C# incorpora el
tipo de dato struct que puede definirse como una clase sencilla que admite interfaces pero no
herencia.
Además de estas características, C# facilita las consultas integradas en una gran variedad de
orígenes de datos mediante Language-Integrated Query (LINQ). Se pueden escribir consultas
sobre bases de datos SQL Server, documentos XML, conjuntos de datos ADO.NET y cualquier
colección de objetos que admite la interfaz IEnumerable.
1.6.1. Hola Mundo en C#
using System;
public class HolaMundo
public static void Main(string[] args)
Console.WriteLine("Hola mundo");
2. Java
2.1. Introducción e historia
Java es un lenguaje de programación de propósito general, multiplataforma y orientado a objetos.

Su objetivo principal es que se escriba código una sola vez y este sea ejecutable en máquinas de
distinta arquitectura. Esto se consigue compilando a un código intermedio llamado bytecode que es
interpretado en el momento de la ejecución por la Máquina Virtual de Java (JVM).
(1)
Java es, según el índice Tiobe (http://www.tiobe.com/tiobe-index), el lenguaje más usado ,
suponiendo el 18,24% del total de líneas de código escritas. Java ha mantenido esta posición
privilegiada desde 2.001, siendo superado por C en contadas ocasiones.
Java fue desarrollado desde 1.991 por un equipo de Sun Microsystems, liderado por James
Gosling, en un proyecto denominado Green Project. Originalmente el lenguaje se denominó Oak
(roble), pero por un problema de patentes pasó a llamarse Java.
Los objetivos iniciales eran implementar un lenguaje con una estructura y sintaxis similar a C++
que pudiera ejecutarse en cualquier tipo de máquina, pero en el verano de 1.994 el equipo
reorientó la plataforma hacia la web. Con esta nueva línea de trabajo, crearon el navegador
HotJava, que fue presentado junto a la primera versión de Java en mayo de 1.995 durante la
conferencia SunWorld.
En enero de 1.996 se publicó la primera versión de Java y desde entonces Java ha experimentado
numerosos cambios, así como la inclusión de gran cantidad de clases y paquetes que se incluyen
en la instalación estándar.
2.2. Características principales
Java comparte muchas de sus características con C++: lenguaje fuertemente tipado, orientado a
objetos, sintaxis similar,… La diferencia fundamental entre ellos es el tratamiento de la memoria,
ya que Java no permite la asignación dinámica de la misma y el uso de punteros.
En Java todo son clases (objetos), siendo obligatorio el uso del paradigma de la Programación a
Objetos. Un programa en Java estará formado por uno o varios ficheros que a su vez contienen
una o más clases. Una de estas clases debe contener un método main que contendrá el código
principal del programa. La declaración de dicho método será:
public static void main ( String args[] )
Como vamos a escribir nuestro primer programa en Java, el clásico “Hola mundo!”:
class Hola {
public static void main(String argumentos[]) {
System.out.println("Hola mundo!");
2.2.1. Comentarios
Como en cualquier lenguaje de programación, los comentarios en Java son de gran valor, ya que
se deben utilizar para hacer más comprensible el código y que este sea mantenible por personas
que no fueron los programadores originales.
En Java existen comentarios de dos tipos:
• De una sola línea: // Esto es un comentario de una línea
• De varias líneas: /* Esto es un comentario
de más de una línea */
2.2.2. Tipos de datos
En Java existen dos tipos de datos principales:
• Tipos de datos primitivos.
• Referencias a objetos.
Entendemos por tipos de datos primitivos aquellos que se pueden definir sin el uso de la POO. En
Java son: byte, short, int, long, float, double, char y boolean.
Tabla I: Tipos de datos primitivos
TIPO Longitud Valor mínimo Valor máximo

byte 1 byte -128 127
short 2 bytes -32.768 32.767
int 4 bytes -2.147.483.648 2.147.483.647
long 8 bytes -9.223.372.036.854.775.808 9.223.372.036.854.775.807
-38 38
float 4 bytes ±3,4*10 ±3,4*10
-308 308
double 8 bytes ±1,7*10 ±1,7*10
char 2 bytes 0 65.535
boolean 1 byte False true
En Java la longitud de los tipos primitivos no depende de la plataforma hardware ni del sistema
operativo. Por contra, no se realizan comprobaciones de rango; esto quiere decir que a una
variable de tipo byte con valor 127 se le suma 1, pasa a valer -128 sin que se produzca error.
Las referencias almacenan un puntero a una zona de memoria que almacena a un tipo de dato
más complejo como son los arrays y los objetos.
Para cada tipo de dato primitivo existe una clase equivalente que tienen métodos que facilitan el
trabajo con variables cómo conversores de tipos.
Tabla II: Equivalencia tipos primitivos y clases
Tipo primitivo Clase

Byte java.lang.Byte
Short java.lang.Short
Int java.lang.Integer
Long java.lang.Long
Flota java.lang.Float
double java.lang.Double
Char java.lang.Character
boolean java.lang.Boolean
En Java las variables se declaran de la misma forma que en C++, identificador (nombre de la
variable) y tipo de dato al que corresponde. Las variables también pueden ser inicializadas durante
la declaración.
int x;
int x = 0;
Los identificadores pueden estar formados por letras, números y símbolos con las siguientes
restricciones:
• No pueden empezar por un número.
• No pueden ser una palabra reservada del lenguaje ni los símbolos de los operadores.
• No se admiten espacios en blanco.
Java distingue entre mayúsculas y minúsculas en el nombre de las variables.
La visibilidad o ámbito de una variable es la parte del programa donde dicha variable puede ser
usada. En Java podemos distinguir los siguientes ámbitos:
• Local: se declaran dentro de un método y son visibles únicamente dentro de éste.
• Atributos: son las características de una clase y su ámbito está limitado al objeto pero
pueden definirse de manera que su comportamiento respecto al ámbito se vea modificado
(ver punto 3.3.5.2).
• Parámetros: son las variables que se pasan a un método. Se declaran en la cabecera del
método. La visibilidad es el método en el que están definidas.
2.2.3. Operadores
Los operadores en Java son muy similares a los de C++. Pueden clasificarse en los siguientes
tipos:
• Asignación: permite asignar un valor a una variable (=).
x = 34;
• Aritméticos: realizan las operaciones habituales de suma (+), resta (-), multiplicación (*),
división (/) y resto de la división (%).
y = x * 4;
Se pueden utilizar junto con el operador de asignación: +=, -=. *=, /= y %=
x *= 4; // x = x * 4;
• Unarios: se utilizan para mantener cambiar el signo de una variable: + (mantener) y -

(cambiar).
y = -x; // y = x * (-1);
• instanceof: permite conocer si un objeto es de una clase.
b = x instanceof String;
• Condicional ?: funciona igual que en C++. Permite asignar valores condicionalmente.
x = 1; y = 2; z = (x>y) ? 10 : 20; // z = 20
• Incrementales: Incrementan (++) o decrementan (--) el valor de la variable a la que

preceden o siguen.
x++; // x = x + 1;
• Relacionales: Se utilizan para realizar comparaciones entre valores de las variables. Mayor
que (>), mayor o igual que (>=), menor que (<), menor o igual que (<=), igual (==) y distinto
(!=).
Se suelen emplear en las sentencias de control (ver punto 3.3.4).
if ( x >= 10 ) y = 20;
• Lógicos: AND (&&), OR (||), negación (!).
if ( a >= 10 && y >= 20) z = 30;
• De bit: actúan a nivel de bits. Desplazamiento a la derecha (>>), desplazamiento a la

izquierda (<<), desplazamiento a la derecha sin signo (>>>), AND a nivel de bits (&), OR a
nivel de bits (|), XOR a nivel de bits (^), complemento a nivel de bits (~).
x = 12; y = x >> 2; // y = 3;
Al igual que los aritméticos se pueden usar junto con el operador de asignación.
x = 12; x >>= 2; // x = 3;
La siguiente tabla muestra la precedencia de las operaciones en Java (de mayor a menor):
Tabla III: Precedencia de operadores
Postfijos [] . ()
Unarios ++ -- - ~ !
Creación o conversión new (tipo) expr
Multiplicación y división */%
Suma y resta +-
Desplazamiento de bits << >> >>>
Relacionales < > <= >=
Igualdad y desigualdad == !=
AND a nivel de bits &
XOR a nivel de bits ^
OR a nivel de bits |
AND lógico &&
OR lógico ||
Condicional ? ?:
Asignación = += -= /= %= ^= &= |= >>= <<= >>>=
2.2.4. Sentencias de control
Las sentencias en Java deben terminar con un punto y coma (;) y se permite tener varias
sentencias en la misma línea. En este aspecto es igual que en C++.
Las sentencias de control se utilizan para modificar el flujo lineal de los programas. Se pueden
clasificar en dos tipos: bifurcaciones y bucle.
2.2.4.1. Bifurcaciones
Permiten ejecutar (o no ejecutar) un conjunto de sentencias en función del valor de una expresión
lógica o relacional.
• if … else: Con esta sentencia se selecciona un conjunto de instrucciones a ejecutar.
if ( expresión ) {
sentencias_A;
else {
sentencias_B;
Si el valor de la expresión se evalúa como verdadero (true) se ejecuta el conjunto de

sentencias_A, si se evalúa como falso (false) se ejecuta el conjunto de
sentencias_B.
Este tipo de bifurcaciones pueden anidarse y concatenarse.
// Anidamiento
if ( expresión_1) {
if ( expresión_2 ) {
...
// Concatenación
...
else if ( expresión_2 ) {
...
else {
...
• switch: Es una variante de la bifurcación if ... else if ... else cuando se utiliza
la misma expresión y se compara con distintos valores.
switch ( expresión ) {
case valor_1: sentencias_A; break;
case valor_2: sentencias_B; break;
case valor_3: sentencias_C; break;
default: sentencias_D;
Cada sentencia case debe corresponderse con un valor concreto, no se puede comparar
con rangos ni expresiones relacionales.
Si la expresión no coincide con ningún valor y existe la sentencia default, se ejecutan las
instrucciones correspondientes (en este ejemplo sentencias_D), si no existe, no se
ejecuta ninguna instrucción.
La sentencia break hace que se salga del bloque switch. Si no existe para alguna de las
sentencias case la ejecución continúa con las sentencias del siguiente bloque case.
2.2.4.2. Bucles
Se utilizan para ejecutar un conjunto de sentencias repetidas veces.
• while: Las sentencias del bloque se ejecutan mientras la expresión se evalúe a verdadero.
while ( expresión ) {
sentencias;
• for: En un bucle for, se indica el número de iteraciones que las sentencias deben
ejecutarse.
for ( inicialización; expresión; incremento) {
sentencias;
Las sentencias de inicialización se ejecutan al inicio del bucle, antes de cada

iteración se evalúa la expresión, si es verdadera se ejecutan las sentencias y si es
falsa finaliza la ejecución del bucle. Las sentencias de incremento se ejecutan después
de las sentencias del bucle.
• do … while: se asegura que las sentencias del bucle se ejecutan al menos una vez.
do {
sentencias;
} while ( expresión );
Las sentencias se vuelven a ejecutar mientras la expresión se evalúe a verdadero.
En los bucles también se puede utilizar la sentencia break para salir de ellos. También se puede
utilizar la sentencia continue para interrumpir la ejecución de una iteración, volver a evaluar la
expresión y si corresponde, ejecutar las sentencias.
2.2.5. Programación orientada a objetos en Java
En Java todo son objetos, por eso es fundamental tener bien asentados los conceptos básicos de
Programación Orientada a Objetos. Por ello vamos a hacer un pequeño repaso a los principales
conceptos y características de la POO.
• Clases y objetos: una clase es un tipo de dato que encapsula tanto las propiedades
(atributos) como los métodos (acciones) que se pueden actuar sobre esas propiedades. Un
objeto es una instancia concreta de ese tipo de dato, es una variable.
• Encapsulación: es la propiedad que tienen los objetos para ocultar sus atributos y/o
métodos. En general, los atributos sólo deberían ser accesibles a través de los métodos.
• Herencia: una clase puede ser definida a partir de otra, de manera que “herede” todos (o
algunos) de sus atributos y métodos. La nueva clase, a su vez, puede definir nuevos
atributos y métodos, y/o redefinir los heredados.
• Polimorfismo: con esta característica se permite que dentro de una jerarquía de clases, un
mismo método se comporte de distinta manera para cada una de las clases.
2.2.5.1. Conceptos de Clase, Objeto e Interface
Una clase es la definición de un tipo de dato donde se agrupan tanto los atributos (variables) que lo
definen como los métodos (funciones) que actúan sobre dichos atributos.
La definición de una clase se realiza:
class NombreDeClase {
// Definición de atributos y métodos
...
Un objeto es una instancia concreta de una clase, una variable del tipo de dato “clase”.
NombreDeClase nombreDeObjeto;
Una interface solamente contiene la declaración de los métodos sin su implementación y en su

caso de constantes. Son las clases que heredan de la interface las que están obligadas a
implementarlos. Al igual que las clases, en Java, una interface puede heredar de otra, pero a
diferencia de las clases, si que tienen herencia múltiple.
interface NombreDeInterface {
// Declaración de métodos y constantes
...
2.2.5.2. Variables miembro
Las variables miembro de una clase son los atributos o características de dicha clase. Cada objeto
de una clase tiene una copia propia de todas las variables miembro. Las variables miembro pueden
ser de tipos primitivos o a su vez pueden ser objetos de otras clases.
Las variables miembro pueden declararse con los modificadores public, private, protected y
package para indicar su nivel de acceso. En la siguiente tabla se especifican los tipos de acceso.
Tabla IV: Modificadores de acceso a miembros
public Se puede acceder al miembro de la clase desde cualquier parte del programa.
private Sólo es accesible desde la propia clase.
protected Se puede acceder desde la propia clase y las clases que heredan de ella.
package Se puede acceder desde las clases incluidas en el mismo paquete.
Se definen como cualquier variable:
class Persona {
public String nombre;
protected int edad;
private char sexo;
...
Las clases pueden tener variables propias de clase que son globales a todos los objetos de esa
clase. Se definen con el modificador static y se suelen utilizar para definir constantes globales
para la clase (deben tener también el modificador final para que no se pueda cambiar su valor) o
variables que tengan sentido a nivel de clase (por ejemplo un contador de objetos de dicha clase).
class Persona {
public static final int MAYORIA_EDAD = 18;
public static long totalPersonas;
public String nombre;
protected int edad;
private char sexo;
...
2.2.5.3. Métodos
Los métodos son funciones definidas dentro de la clase y que actúan sobre las variables miembro.
Se aplican siempre sobre el objeto que invoca a la función mediante el operador punto (.). Este
objeto es un argumento implícito y se accede a sus variable miembro directamente o con el
operador this.
class Persona {
public boolean esMayorDeEdad() {
if ( this.edad >= Persona.MAYORIA_EDAD )
return true;
else
return false;
Persona p1 = new Persona();
if ( p1.esMayorDeEdad() )
System.out.println(“Puede votar.”);
else
System.out.println(“No puede votar.”);
Java permite que las subclases redefinan los métodos heredados, es decir, que el método tendrá
el mismo nombre y parámetros que el de la superclase pero distinta funcionalidad.
Del mismo modo que C++, también se permite la sobrecarga de métodos, esto es, métodos que
tiene el mismo nombre pero distintos parámetros de entrada y distinta funcionalidad.
Los métodos pueden declararse con los modificadores public, private y protected para
indicar su nivel de acceso. La visibilidad de estos modificadores en la misma que para las variables
miembro (ver Tabla IV).
Además de los modificadores de acceso, existen los siguientes modificadores en la declaración de

métodos:
• static: estos métodos se consideran pertenecientes a la clase y, por tanto, no es

necesario instanciar un objeto para utilizarlos.
• abstract: este modificador implica que el método sólo tiene definida su declaración, no
su implementación. Las clases que hereden estos métodos están obligadas a
implementarlos. Cuando una clase define este tipo de métodos, la clase también debe
definirse como abstract.
• final: estos métodos no pueden ser redefinidos por las subclases.
Unos métodos de especial importancia en la definición de clases son los constructores. Estos
métodos son los que se ejecutan automáticamente cada vez que se crea un objeto de la clase
(cada vez que se invoca a new). Realizan la reserva de memoria y la inicialización de variables. Su
nombre es el mismo que el de la clase y no tiene valores de retorno. No pueden ser llamados por
otros métodos, sólo por otros constructores o por método static. Si no se define un constructor
explícitamente, el compilador “crea” un constructor genérico que inicializa las variables miembro.
2.2.5.4. Paquetes
Un paquete (package) es una agrupación de clases que normalmente tienen una relación
funcional, p. e. se puede definir un paquete geometría que contengas clases como Círculo,
Triángulo, Cuadrado, etc.
Para incluir una clase en un paquete, la sentencia del fichero donde se define la clase debe ser
package seguida del nombre del paquete.
package es.ciencias.matematicas.geometria;
El nombre de los paquetes suelen ser en minúsculas y contener varios segmentos unidos por
puntos. Estos segmentos están relacionados con la jerarquía de los paquetes y contienen todas las
clases relacionadas en el mismo directorio.
CLASSPATH\es\ciencias\matematicas\geometria\Circulo.class
En el momento de invocar a una clase, se debería utilizar el nombre completo del paquete unido al
de la clase.
es.ciencias.matematicas.geometria.Circulo
Para evitar la dificultad de usara estos nombre “largos” se pueden importar todas las clases de un
paquete y utilizarlas con su nombre corto.
import es.ciencias.matematicas.geometria.*;
2.2.5.5. Herencia
Esta es una de las características principales de la POO ya que permite una fácil reutilización de
código.
Con la herencia se puede construir una clase (subclase) a partir de otra clase existente
(superclase) de manera que se heredan todos los atributos y métodos (excepto las definidas con el
modificador private). Los métodos que se heredan pueden ser redefinidos (excepto los definidos
con el atributo final) de manera que se altere su funcionalidad para adaptarla a la nueva clase y
también se permite que los métodos de la superclase puedan ser llamados desde la subclase
mediante la sentencia super. Puede decirse que una subclase amplia la funcionalidad de la
superclase.
class Empleado extends Persona {
// De la clase Persona se heredan las variables miembro
// nombre y edad que no hace falta definir.
public long numeroEmpleado;
protected String dni;
private char sexo; // Vuelvo a definir sexo que no se hereda
...
Java permite varios niveles de herencia, pero no permite la herencia múltiple (una subclase hereda
de varias superclases). Para suplir esta carencia Java implementa las Interfaces que veremos a
continuación.
2.2.5.6. Interfaces
Una interface es un conjunto de declaraciones de métodos sin su implementación, y, en su

caso, también la definición de constantes. Todas las clases que implemente una determinada
interface están obligadas a implementar los métodos definidos en la misma. Una clase puede
implementar (heredar) varias interfaces.
interface Dibujable {
public void dibujar ();
class Circulo {
protected double x, y, r;
...
class CirculoDibujable extends Circulo implemts Dibujable {
//Esta clase debe definir obligatoriamente el método dibujar()
public void dibujar () {
...
...
Las interfaces sólo admiten los modificadores public y package. Los métodos definidos en la
interface son siempre public y abstract (este de manera implícita).
Independientemente de la herencia entre clases, también se permite la herencia entre interfaces,

que esta si que puede ser múltiple. Para le herencia de interfaces se utiliza la sentencia extends.
2.2.5.7. Paquetes java.langa y java.util
Son los dos paquetes principales que incluye la API de Java. El primero contiene clases
imprescindibles para Java y es importado por defecto. El segundo contiene clases diversas pero
también muy útiles a la hora de programar.
• java.lang: contiene las clases equivalente a los tipos primitivos de datos y las clases
String, StringBuffer, System y Math, entre otras. También incluye las interfaces
Cloneable, Comparable e Iterable.
• java.util: contiene clases importantes como ArrayList, Date, Formatter, Hashtable,

Objects, Random, Stack, Timer, Vector; también incluye las interfaces Collection,
Enumeration, Iterator y List.
2.2.6. Excepciones
Java incorpora en el propio lenguaje mecanismo para el tratamiento de errores. Una excepción
puede definirse como una anomalía o un funcionamiento no esperado durante la ejecución de un
programa (división por cero, fichero no existe, tamaño del array excedido, etc.).
Las excepciones nos permiten gestionar estos errores y recuperarnos en caso de un error no grave
(p. e. volver a pedir el fichero en caso de que no exista) o finalizar el programa de forma ordenada
en caso de un error fatal (p. e. división por cero).
La clase Exception es la que proporciona Java para el tratamiento de errores. El proceso de

captura y tratamiento de errores es el siguiente:
• Bloque try: en este bloque se incluyen todas las sentencias susceptibles de producir el
error que se quiere tratar. Si este error se produce, la secuencia de ejecución del programa
salta al bloque catch.
• Bloque catch: aquí se define que hacer cuando se ha producido un error en el bloque
anterior. Se pueden incluir tantos bloques catch como sean necesarios, uno para cada
tipo de error que se quiera tratar.
Si en este bloque no se desea tratar el error y se quiere que sea tratado por el método
llamador, se debe “relanzar” la excepción con la sentencia throw. Para poder relanzar
excepciones, estas se deben incluir en la definición del método:
void validaNumero(String strNumero) throws NumberFormatException {
int numero = 0;
try {
numero = Integer.parseInt( strNumero );
catch ( NumberFormatException ex ) {
throw ex;
• Bloque finally: este bloque es opcional pero si se incluye, sus sentencias se ejecutan
siempre independientemente de si ha habido error o no, y del tipo del error.
try {
// Sentencias para controlar errores
catch (ExceptionClass1 ex1) {
// Sentencias para tratar la excepción 1
finally {
// Sentencias que se ejecutan SIEMPRE
2.2.7. E/S en Java
La forma que tiene Java para manejar los flujos de entrada y salida de datos a los programas es
mediante los streams (flujos de datos). Podemos definir un stream como una conexión entre el
programa y la fuente de datos.
P. e. cuando se quiere escribir en un fichero se hace a través de un stream, se utiliza este canal
tanto para leer como para escribir. Este mecanismo se utiliza de manera similar sea cual sea la
fuente de datos: ficheros, sockets, pantalla, teclado,…
Las clases que se utlizan para la entrada de datos están contenidas en el paquete java.io. Estas
clases pueden dividirse en clases para la lectura de datos y clases para la salida de datos, y dentro
de estas, clases que trabajan con bytes y clases que trabajan con caracteres.
La nomenclatura de las clases del paquete java.io está sistematizada, de manera que permite
deducir la función de la clase a partir de su nombre.
Tabla V: Nomenclatura de java.io
InputStream, OutoputStream Lectura/Escritura de bytes.

Reader, Writer Lectura/Escritura de caracteres.
File Ficheros
String, CharArray, ByteArray,
Tipo de dato a leer.
StringBuffer
Piped Pipe (tubo de datos).
Buffered Buffer de datos.
Print Imprimir.
De esta manera, se puede deducir la función de estas clases: FileReader, FileWriter,

FileInputStream, FileOutputStream, StringReader, StringWriter, etc…
La E/S de datos estándar por teclado y pantalla se realiza mediante la clase System que pertence
al paquete java.lang. Esta clase tiene tres objetos principales para manejar la E/S:
• System.in: Objeto de la clase InputStream para recibir datos del dispositivo por
defecto (teclado). Se utiliza el método read().
• System.out: Objeto de la clase PrintStream para escribir en el dispositivo por defecto

(pantalla). Se utilizan los métodos print() y println().
• System.err: Objeto de la clase PrintStream para escribir mensajes de error en el

dispositivo por defecto (pantalla). Se utilizan los métodos print() y println().
Se puede modificar el dispositivo de entrada y salida por defecto con los métodos setIn(),
setOut() y setErr().
2.2.8. Hilos (Threads)
En la actualidad, los procesadores y los sistemas operativos permiten le ejecución simultanea de

varios programas, esto es lo que se conoce como multitarea. Los procesadores que disponen de
más de una CPU realizan multitarea “real”, mientras los que tienen una única CPU utilizan los
tiempos muertos de unos procesos (p. e. lectura/escritura de ficheros) para ejecutar otros procesos
y “simular” la multitarea.
Algunos conceptos básicos sobre multitarea:
• Proceso: programa que se ejecuta de manera independiente con su propio espacio de

memoria.
• Hilo (thread): es un flujo secuencial de instrucciones dentro de un proceso.
P. e. un editor de textos es un proceso, y cada uno de los documentos que estamos editando sería
un hilo de ejecución.
Figura 4: Un programa con un hilo (A) y un programa con dos hilos (B)
En Java existen dos formas de crear hilos. La primera consiste en crear una clase que herede de la
clase Thread y redefina el método run().
public class miThread extends Thread {
// El construcctor llama al de la clase Thread
public miThread ( String str ) {
super ( str );
// Redefinción del método run()
public void run () {
System.out.println ( “Este es el hilo: “ + getName() );
miThread objetoThread = new miThread(“HiloDePrueba”);
objetoThread.start();
La segunda consiste en la definición de una clase que derive de la Interfaz Runnable y que
implemente el método run(); a continuación se crea un objeto de esta clase (objetoRunnable)
y otro objeto de la clase Thread (objetoThread) pasándole al constructor el objetoRunnable.
public class miRunnable implements Runnable {
// Variable con el nombre del hilo
String nombreThread;
// Constructor
public miRunnable ( String str ) {
nombreThread = str;
// Definición del método run()
public void run() {
System.out.println ( “Este es el hilo: “ + nombreThread);
miRunnable objetoRunnable = new miRunnable(“HiloDePrueba”);
Thread objetoThread = new Thread(objetoRunnable);
objetoThread.start();
2.2.9. Herramientas de Java
El entorno de desarrollo Java (JDK) proporciona una sería de herramientas para facilitar la
creación de aplicaciones. Las herramientas básicas son:
• javac: compila los ficheros fuente (.java) que se le pasan como parámetro. Genera tantos
ficheros en bytecodes (.class) como clases tenga el fichero fuente.
• java: interprete de los ficheros de bytecodes (.class). Ejecuta los ficheros que se le
pasan como parámetro.
• jdb: depurador de línea de comandos. Se utiliza para encontrar y corregir errores.
• javah: genera ficheros cabeceras en formato C para comunicar aplicaciones en Java con
aplicaciones programadas en C.
• javap: desensamblador que a partir de ficheros en bytecodes (.class) muestra

información sobre dicha clase (atributos y métodos).
• javadoc: generador de documentación. A partir de los comentarios de los ficheros de

fuentes genera documentación de las clases en formato html.
2.3. Principales frameworks
Un framework (entorno de trabajo) para aplicaciones web es un conjunto de herramientas, librerías

y estilo de programación que facilita y hace comprensible para otros programadores el desarrollo
de aplicaciones.
Las ventajas de utilizar un framework son:
• Evitar la programación de funciones y tareas repetitivas que aparecen en todos los

proyectos (conexión a base de datos, envío de mails, gestión de errores, …).
• Minimizar el riesgo de aparición de errores al utilizar unas rutinas que han sido
ampliamente probadas.
• Ordenar el proyecto creando una estructura de la aplicación concreta.
• Sistematizar la nomenclatura de la aplicación.
También el uso de un framework implica algunos inconvenientes:
• Tiempo de aprendizaje de aprendizaje. Algunos frameworks requieren invertir mucho

tiempo de aprendizaje.
• El proceso de configuración de la aplicación puede ser complejo.
• Complejidad del código escrito por terceros.
En cada proyecto se debe valorar la necesidad o no de utilizar un framework.
2.3.1. Spring
Spring fue desarrollado inicialmente por Rod Johnson quien lo liberó en 2.002 junto a la publicación
de su libro Expert One-on-One J2EE Design and Development. Actualmente es desarrollado por
SpringSource.
El framework incluye diversos módulos, siendo los principales:
• Contenedor de inversión de control: administra el ciclo de vida de los objetos Java,

principalmente a través de la inyección de dependencias.
• Acceso a datos: permite el acceso a datos mediante el uso de JDBC y ORM.
• Modelo-Vista-Controlador: implementa el patrón MVC basado en HTTP y servlets.
• Acceso remoto: permite la importación y exportación, al estilo de RPC, de objetos Java.
• Autenticación: incorpora procesos de seguridad configurables para la autenticación de

usuarios.
3. PHP
3.1. Introducción
(2)
PHP (Hipertext Preprocessor) es un lenguaje interpretado de propósito general. Su sintaxis es
similar a C, Java y Perl.
Al ser de propósito general puede ser utilizado para:
• Programación web: Este es su uso principal. El interprete de PHP se ejecuta en un servidor

web y se generan páginas web dinámicas.
• Programación en consola: Se crean aplicaciones de consola.
• Programación de interfaces gráficas: Usando la extensión PHP-GTK se pueden programar

aplicaciones con interface gráfica.
3.2. Historia
PHP fue creado por Rasmus Lerdorf en 1994 como un conjunto de herramientas para sustituir a los
scripts de Perl que utilizaba Rasmus para su página web personal. En 1995 se lanzó la primera
versión de PHP para el público en general (PHP v2).
En 1997 Zeev Suraski y Andi Gutmans, reescribieron la mayor parte del núcleo de PHP y lanzaron,
junto con Rasmus, la versión 3.
Zeev y Andi fundaron Zend Technologies y continuaron con la mejora del núcleo de PHP para en el
año 2000 lanzar la versión 4.
En 2004 se publica la versión 5 de PHP que ya incluye soporte completo para la programación
orientada a objetos. También se incluyeron características importantes como una capa de
abstracción para el acceso a base de datos (PDO - PHP Data Objects), tratamiento de
excepciones y mejoras en el tratamiento de XML. Esta versión supuso un punto de ruptura con la
versión 4, ya que prácticamente los programas desarrollados con PHP 4 eran incompatibles con la
nueva versión PHP 5. En 2008 se dejó de dar soporte a la versión PHP 4.
El desarrollo de PHP continuó y en 2009 se lanzó la versión 5.3 con importantes características
como los espacios de nombres y funciones anónimas. En 2012 se publicó PHP 5.4, en 2013 la
versión 5.5 y en 2014 PHP 5.6.
La versión actual es PHP 7 que se lanzó en noviembre de 2015
3.3. Características principales
El uso principal de PHP es de programación web. Es un lenguaje del lado del servidor (es el
servidor web el que ejecuta el interprete) que puede ser embebido en las páginas HTML de una
web.
Un ejemplo sencillo. El fichero index.php contiene el siguiente código PHP embebido en código
HTML.
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<title>Hola mundo PHP</title>
</head>
<body>
<?php
echo 'Hola mundo!';
?>
</body>
</html>
El cliente solicita al servidor a través de Internet la página index.php. El servidor detecta que
esta página debe ser preprocesada antes de enviarla e invoca al intérprete de PHP para que la
procese y genere la página index.html que se devuelve al cliente.
Figura 5: Esquema de ejecución de un script PHP
El código HTML que recibe el cliente es el siguiente:
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<title>Hola mundo PHP</title>
</head>
<body>
Hola mundo!
</body>
</html>
3.3.1. Delimitadores y comentarios
Como se puede apreciar en el ejemplo anterior, el código PHP embebido en páginas HTML está
escrito entre los delimitadores <?php y ?>. Estos delimitadores son los más comunes, pero existen
otros:
<?php ... ?>
<? ... ?>
<script language=”php”> ... </script>
<?= ... ?> Delimitador de expresiones en línea. P. e. <?= 2+2 ?>
Los comentarios en PHP son similares a los de C++ o Java. Comentarios de una sola línea (// o
#) y comentarios de más de una línea (/* ... */).
3.3.2. Variables
En PHP no es necesario declarar una variable antes de usarla, se creará simplemente la primera
vez que se asignemos un valor. El nombre de las variables (identificadores) deben cumplir las
siguientes reglas:
• Deben empezar por $.
• Pueden tener cualquier longitud e incluir letras, número y guiones bajos.
• En los nombres de variables se distingue entre mayúsculas y minúsculas.
• Un variable puede tener el mismo nombre que una función.
Respecto a los tipos de datos, PHP es un lenguaje débilmente tipado, es decir, no controla los
tipos de datos de las variables que se declaran. El tipo de dato de una variable dependerá en cada
momento del valor que tenga asignado.
$num_productos = 10; // La variable se declara de tipo entero
$num_productos = 11.0; // La variable pasa a ser de tipo doble
Los tipos de datos admitidos en PHP son: entero, flotante o doble, cadena, booleano, array o
conjunto de datos y objeto.
Una particularidad de PHP es que se permite el uso del tipo “variable”. Esto lo veremos mejor con
un ejemplo:
$nombre_variable = ‘num_productos’;
$$nombre_variable = 5; // Equivale a $num_productos = 5
En cuanto a la visibilidad o ámbito de las variables, las podemos clasificar en:
• Locales: su ámbito es el de la función en la que se crean.
• Globales: su visibilidad es en cualquier parte del código excepto en el interior de una

función.
• Superglobales: variables que se pueden utilizar en cualquier script de la aplicación.

Algunas de estas variables creadas por PHP son $GLOBALS, $_GET, $_POST y
$_SESSION.
3.3.3. Operadores
Los operadores en PHP son muy similares a los de otros lenguajes de programación. Pueden
clasificarse en los siguientes tipos:
• Asignación: permite asignar un valor a una variable (=).
$x = 34;
• Aritméticos: realizan las operaciones habituales de suma (+), resta (-), multiplicación (*),
división (/), resto de la división (%) y exponente (**)
$y = $x * 4;
Se pueden utilizar junto con el operador de asignación: +=, -=. *=, /= y %=
$x *= 4; // $x = $x * 4;
• Unarios: se utilizan para mantener cambiar el signo de una variable: + (mantener) y -

(cambiar).
$y = -$x; // $y = $x * (-1);
• instanceof: permita conocer si un objeto es de una clase.
$b = $x instanceof String;
• Condicional ?: funciona igual que en C++. Permite asignar valores condicionalmente.
$x = 1; $y = 2; $z = ($x > $y) ? 10 : 20; // $z = 20
• Incrementales: Incrementan (++) o decrementan (--) el valor de la variable a la que

preceden o siguen.
$x++; // $x = $x + 1;
• Relacionales: Se utilizan para realizar comparaciones entre valores de las variables. Mayor
que (>), mayor o igual que (>=), menor que (<), menor o igual que (<=), igual (==) y distinto
(!=).
En PHP existen dos operadores especiales, de identidad, que además de comparar el valor
verifican que el tipo de dato sea el mismo en los dos elementos.
Se suelen emplear en las sentencias de control (ver punto 4.3.4).
if ( $x >= 10 ) $y = 20;
• Lógicos: AND (&& o and), OR (|| o or), negación (!) y OR-exclusiva (xor).
if ( $a >= 10 && $y >= 20) $z = 30;
• De bit: actúan a nivel de bits. Desplazamiento a la derecha (>>), desplazamiento a la

izquierda (<<), AND a nivel de bits (&), OR a nivel de bits (|), XOR a nivel de bits (^),
complemento a nivel de bits (~).
$x = 12; $y = $x >> 2; // $y = 3;
• De cadena: Concatenador de cadenas (.).
$a = ‘Hola’; $b = ‘Mundo!’; $c = $a . ‘ ‘ . $b; // $c = ‘Hola Mundo!’
Al igual que los aritméticos se pueden usar junto con el operador de asignación.
$a = ‘Hola’; $a .= ‘ Mundo!’; // $a = ‘Hola Mundo!’
La siguiente tabla muestra la precedencia de las operaciones en PHP (de mayor a menor). Cuando
dos operadores tienen la misma precedencia, su asociatividad decide como se agrupan. Los
operadores de igual precedencia que no son asociativos no pueden usarse unos junto a otros.
(3)
Tabla VI: Precedencia de operadores
Asociatividad Operadores
no asociativo clone new
izquierda [
derecha **
derecha ++ -- ~ (int) (float) (string) (array) (object) (bool) @
no asociativo instanceof
derecha !
izquierda */%
izquierda +-.
izquierda << >>
no asociativo < <= > >=
no asociativo == != === !== <> <=>
izquierda &
izquierda ^
izquierda |
izquierda &&
izquierda ||
derecha ??
izquierda ?:
derecha = += -= *= **= /= .= %= &= |= ^= <<= >>=
izquierda and
izquierda xor
izquierda or
3.3.4. Sentencias de control
Las sentencias en PHP deben terminar con un punto y coma (;) y se permite tener varias
sentencias en la misma línea. En este aspecto es igual que en C++ o Java.
Al igual que en otros lenguajes de programación, las sentencias de control permiten modificar el
flujo lineal de los programas. Se clasifican en dos tipos: bifurcaciones y bucles.
3.3.4.1. Bifurcaciones
En función del valor de una expresión lógica o relacional se ejecuta un flujo de sentencias u otro.
• if … else: Con esta sentencia se selecciona un conjunto de instrucciones a ejecutar.
if ( expresión ) {
sentencias_A;
else {
sentencias_B;
Si el valor de la expresión se evalúa como verdadero (true) se ejecuta el conjunto de

sentencias_A, si se evalúa como falso (false) se ejecuta el conjunto de
sentencias_B.
Este tipo de bifurcaciones pueden anidarse y concatenarse.
// Anidamiento
if ( expresión_1) {
...
// Concatenación
...
elseif ( expresión_2 ) {
...
else {
...
Cuando el código PHP se ejecuta embebido en una página HTML, existe una sintaxis
alternativa:
<?php
if( condicion ) :
?>

<?php
endif;
?>
• switch: Es una variante de la bifurcación if ... else if ... else cuando se utiliza
la misma expresión y se compara con distintos valores.
switch ( expresión ) {
case valor_1: sentencias_A; break;
case valor_2: sentencias_B; break;
case valor_3: sentencias_C; break;
default: sentencias_D;
Cada sentencia case debe corresponderse con un valor concreto, no se puede comparar
con rangos ni expresiones relacionales.
Si la expresión no coincide con ningún valor y existe la sentencia default, se ejecutan las
instrucciones correspondientes (en este ejemplo sentencias_D), si no existe, no se
ejecuta ninguna instrucción.
La sentencia break hace que se salga del bloque switch. Si no existe para alguna de las
sentencias case la ejecución continúa con las sentencias del siguiente bloque case.
3.3.4.2. Bucles
Se utilizan para ejecutar un conjunto de sentencias repetidas veces.
• while: Las sentencias del bloque se ejecutan mientras la expresión se evalúe a verdadero.
while ( expresión ) {
sentencias;
alternativa:
<?php while( condicion ) : ?>
<?php endwhile; ?>
• do … while: se asegura que las sentencias del bucle se ejecutan al menos una vez.
do {
sentencias;
} while ( expresión );
Las sentencias se vuelven a ejecutar mientras la expresión se evalúe a verdadero.
• for: En un bucle for, se indica el número de iteraciones que las sentencias deben
ejecutarse.
for ( inicialización; expresión; incremento) {
sentencias;
Las sentencias de inicialización se ejecutan al inicio del bucle, antes de cada

iteración se evalúa la expresión, si es verdadera se ejecutan las sentencias y si es
falsa finaliza la ejecución del blucle. Las sentencias de incremento se ejecutan después
de las sentencias del bucle.
alternativa:
<?php for( expresion1; expresion2; expresion3 ) : ?>
<?php enfor; ?>
• foreach: Es una implementación especial de los bucles for que nos permite iterar de forma
sencilla sobre los elementos de un array.
foreach( expresion_array as $valor ){
sentencias;
Ejecuta el bucle para todos los elementos del array.
Existe una sintaxis alternativa que nos permite recuperar tanto el valor del elemento del
array como el índice.
foreach( expresion_array as $indice => $valor ){
sentencias;
En los bucles también se puede utilizar la sentencia break para salir de ellos. También se puede
utilizar la sentencia continue para interrumpir la ejecución de una iteración, volver a evaluar la
expresión y si corresponde, ejecutar las sentencias.
3.3.5. Arrays
Los arrays son tipos de datos que permiten, bajo un mismo nombre de identificador, almacenar un
conjunto de valores. Al igual que el resto de variables, en PHP no es necesario declarar un array
antes de empezar a utilizarlo, tampoco es necesario reservar memoria para el mismo.
(4)
Una característica particular de PHP es que existen dos formas de indexar los arrays:
• Indexación numérica: se accede a los elementos del array por medio de un índice
numérico. El índice empieza en el valor 0.
$productos = array ('Tornillos', 'Clavos', 'Martillo');
echo $productos[1]; // Clavos
$productos[] = ‘Tuercas’; // $productos[3] = ‘Tuercas’;
• Indexación asociativa: la clave para acceder a los elementos del array es una cadena
alfanumérica.
$precios = array ( ‘Tornillos’ => 0.20,
‘Clavos’ => 0.15,
‘Martillo’ => 17.50,
‘Tuercas’ => 0.25
);
echo $precios[‘Martillo’]; // 17.50
Para recorrer los elemento de un array podemos utilizar las sentencias for y foreach (este es el
único que se puede aplicar a los arrays asociativos).
Una de las funcionalidades que nos proporciona PHP es que incorpora una variada selección de
funciones de ordenación de arrays:
• sort() y rsort(): ordena en array (ascendente o descendentemente) en función de sus

valores.
• asort() y arsort(): ordena en array (ascendente o descendentemente) en función de

sus valores. Se utiliza en arrays asociativos.
• ksort() y krsort(): ordena en array (ascendente o descendentemente) en función de

sus claves. Se utiliza en arrays asociativos.
En PHP también existen operadores espaciales para el tratamiento de arrays:
Tabla VII: Operadores para arrays
Operador Función
$a + $b Unión de los arrays $a y $b
$a == $b Devuelve true si $a y $b tienen los mismos elementos
$a === $b Devuelve true si $a y $b tienen los mismos elementos y
en el mismo orden
$a != $b ó Devuelve true si $a y $b no tienen los mismos elementos
a <> $b
$a !== $b Devuelve true si $a y $b tienen los mismos elementos o
no están en el mismo orden
3.3.6. Funciones y reutilización de código
Como en otros lenguajes como C, las funciones en PHP encapsulan una porción de código que
puede ser ejecutado desde cualquier parte del programa donde se invoque la función.
Para definir una función se escribe la sentencia function seguida del nombre de la función y la lista
de parámetros entre paréntesis y el código entre llaves. Hay que señalar que PHP no distingue
entre mayúsculas y minúsculas cuando se trata del nombre de funciones. Tampoco se permite
sobrecargar el nombre de una función ni que estos empiecen por un número.
Para invocar a una función, simplemente hay que escribir su nombre seguido de los parámetros
entre paréntesis.
function suma ( $a, $b ) {
return ( $a + $b );
echo suma(3, 5); // 8
PHP permite que se definan funciones con un número variable de parámetros, los obligatorios
siempre se definen los primeros y los optativos tienen un valor predeterminado.
function calcula_iva ( $importe, $iva = 21) {
return ( $importe * ( ( $iva / 100 ) + 1 ) );
calcula_iva (1000); // 1210
calcula_iva (1000,4); // 1040
Los parámetros se pueden pasar por valor o por referencia. Si se pasan por valor, se hace una
copia del parámetro de tal manera que si se modifica su valor dentro de la función no se ve
alterado el valor original que tuviera antes de llamarla. Si pasamos los parámetros por referencia,
en realidad se está pasando un puntero a la variable, de tal manera que si se modifica el valor
dentro de la función también se modifica el valor original.
// Por valor
function incrementa ( $valor, $incremento = 1 ) {
$valor = $valor + $incremento;
$a = 1;
incrementa ($a);
echo $a; // 1
// Por referencia
function incrementa ( &$valor, $incremento = 1 ) {
$valor = $valor + $incremento;
$a = 1;
incrementa ($a);
echo $a; // 2
Es posible reutilizar código de un script desarrollado en un fichero en otro diferente. PHP incorpora
sentencias similares a #include de C++:
• include(): añade el código incluido en el fichero que se le pasa como parámetro. Si el

fichero no existe continúa la ejecución del script.
• require(): añade el código incluido en el fichero que se le pasa como parámetro. Si el

fichero no existe detiene la ejecución del script.
3.3.7. Programación orientada a objetos en PHP
Desde PHP 5 se incluye soporte completo para la programación orientada a objetos. Al igual que
en otros lenguajes que soportan la POO, PHP implementa las características principales de la
POO:
• Encapsulación: los atributos y/o métodos de los objetos pueden estar ocultos
(encapsulados) y no ser accesibles desde el exterior del objeto.
• Herencia: una clase puede ser definida a partir de otra, de manera que “herede” todos (o
algunos) de sus atributos y métodos.
• Polimorfismo: dentro de una jerarquía de clases, un mismo método puede comportarse de

distinta manera para cada una de las clases.
3.3.7.1. Conceptos de Clase, Objeto e Interface
Al igual que en otros lenguajes, en PHP una clase es la definición de un tipo de dato donde se
agrupan tanto los atributos (propiedades) que lo definen como los métodos (comportamiento).
La definición de una clase se realiza:
<?php
class NombreDeClase {
// Definición de atributos y métodos
...
?>
Un objeto es una instancia concreta de una clase, una variable del tipo de dato “clase”.
<?php $varible_objeto = new NombreDeClase(); ?>
Una interface solamente contiene la declaración de los métodos sin su implementación y en su

caso de constantes. Son las clases que heredan de la interface las que están obligadas a
implementarlos.
<?php
interface NombreDeInterface {
// Declaración de métodos y constantes
...
?>
3.3.7.2. Atributos
Los atributos son las propiedades de las clases, sus variables miembro. Cada objeto de la clase
tiene su propia copia de todos los atributos.
Al igual que en otros lenguajes, los atributos pueden definirse con los modificadores public,
private y protected para restringir su nivel de acceso. En la siguiente tabla se especifican los
tipos de acceso.
Tabla VIII: Modificadores de acceso a miembros
public Se puede acceder desde fuera de la clase.

private Sólo es accesible desde dentro de la propia clase.
protected Se puede acceder desde la propia clase y las clases que heredan de ella.
<?php
class Persona {
public $nombre;
protected $edad;
private $sexo;
...
?>
Las clases pueden tener variables propias de clase que son globales a todos los objetos de esa
clase, se definen con el modificador static (por ejemplo un contador de objetos de dicha clase).
También se pueden definir constantes globales para la clase con el modificador const. El acceso
a estas variable y constantes se realiza con el operador dos puntos-dos puntos (::).
<?php
class Persona {
const $MAYORIA_EDAD = 18;
static $totalPersonas;
public $nombre;
protected $edad;
private $sexo;
...
?>
3.3.7.3. Métodos
Los métodos son funciones que definen el comportamiento de los objetos de una clase, actúan
sobre los atributos. Se aplican siempre sobre el objeto que invoca a la función mediante el
operador flecha (->). El propio objeto es un argumento implícito y se accede a sus atributos y
métodos mediante la variable $this.
<?php
class Persona {
protected $nombre;
protected $edad;
function esMayorDeEdad() {
if ( $this->edad >= 18 )
return true;
else
return false;
$p1 = new Persona();
if ( $p1->esMayorDeEdad() )
echo ‘Puede votar’;
else
echo ‘No puede votar.’;
?>
PHP, permite que las subclases redefinan los métodos heredados, es decir, que el método tendrá
el mismo nombre y parámetros que el de la superclase pero distinta funcionalidad. Esta
funcionalidad puede evitarse con el modificador final, esto impide que la subclase redefina un
método.
Al igual que otros lenguajes, también se permite la sobrecarga de métodos, pero en PHP esto es
algo mas complicado que en otros lenguajes. Se implementa mediante el método “mágico”
__call(). Este método se ejecuta automáticamente cuando se invoca a un método que no existe
o no es accesible, como parámetro recibe el nombre del método invocado y un vector con los
parámetros con lo que se ha llamado a ese método. Mediante este método mágico, se puede
implementar la sobrecarga de métodos:
<?php
class Calculadora {
protected $resultado;
function __call($fName, $fArgs) {
switch ($fName) {
case ‘suma’:
if (count($fArgs)===1) {
$this->resultado = $fArgs[0];
else {
$this->resultado = 0;
foreach($fArgs as $arg) {
$this->resultado += $arg;
return $this->resultado;
break;
default:
die(‘Error: no existe el método ‘ . $fName);
break;
$c = new Calculadora();
echo $c->suma(4); // 4
echo $c->suma(4,3); // 7
echo $c->suma(4,3,5); // 12
echo $c->resta(5,4); // Error: no existe el método resta
?>
Los métodos “mágicos” son aquellos que son llamados automáticamente por PHP ante
determinadas situaciones. En las clases, los métodos mágicos que se pueden implementar son:
Tabla IX: Métodos mágicos en clases
__construct El constructor de clases. Se invoca con la sentencia new.

__destruct Se invoca cuando un objeto es destruido.
__toString Se llama cuando se imprime un objeto. P. e. con la sentencia echo.
__set Asigna un valor a un atributo del objeto. Se invoca con el operador
__get Obtiene el valor de un atributo. Se invoca con el operador
__clone Se utiliza para la copia de objetos. Se invoca con la sentencia clone.
Sirve para implementar la sobrecarga de métodos. Se llama cuando se invoca a un
__call
método que no existe en la clase.
3.3.7.4. Herencia
Esta es una de las características principales de la POO ya que permite la reutilización de código.
Para ello unas clases pueden ser extensiones de otras. La clase extendida (derivada o subclase)
conserva todos los atributos y métodos de la clase base (superclase). Las subclases pueden
añadir nuevos atributos y métodos, pero no es posible disminuir una clase, es decir, eliminar la
definición de cualquier atributo o método de la superclase.
Al igual que Java, en PHP se permite implementar varios niveles de herencia (jerarquía), pero no
permite la herencia múltiple.
3.3.7.5. Interfaces
Al igual que en otros lenguajes, una interface es un conjunto de declaraciones de métodos sin
su implementación, y, en su caso, también la definición de constantes. Todas las clases que
hereden una determinada interface están obligadas a implementar los métodos definidos en la
misma. Una clase puede implementar (heredar) varias interfaces.
Independientemente de la herencia entre clases, también se permite la herencia entre interfaces,

que esta si que puede ser múltiple. Para le herencia de interfaces se utiliza la sentencia extends.
3.3.8. Excepciones
Como ya hemos visto en este texto, una excepción puede definirse como un funcionamiento no
esperado durante la ejecución de un programa que nos permite recuperarnos en caso de un error
no grave (p. e. volver a pedir el fichero en caso de que no exista) o finalizar el programa de forma
ordenada en caso de un error fatal (p. e. división por cero).
La gestión de los errores mediante excepciones fue una de las principales novedades que se
introdujo en PHP 5.
Al igual que otros lenguajes que implementan el manejo de errores con excepciones, PHP
incorpora la clase Exception y los bloques try, catch y finally (sólo a partir de PHP 5.5).
La clase Exception es la que proporciona Java para el tratamiento de errores.
3.4. Principales frameworks
El concepto de framework ya se introdujo en el punto 2.3
En PHP existe un amplísimo listado de frameworks: Symfony, CakePHP, Codeigniter, Zend,

Kohana, Yii, Laravel, Slim, … y un largo etcétera. A continuación vamos a comentar tres de los
más utilizados actualmente, destacando sus características principales.
3.4.1. Codeigniter
Codeigniter es un framework de PHP desarrollado originalmente por la empresa EllisLab y

actualmente está mantenido por el British Columbia Institute of Technology. Está basado en el
(5)
patrón de programación Modelo-Vista-Controlador y su primera versión se publicó en 2.006.
Sus características principales son:
• Curva de de aprendizaje baja: sólo se requieren conocimientos básicos de POO.
• Patrones: implementa el patrón MVC pero no de manera estricta ya que permite que las
aplicaciones funcionen únicamente con el controlador y la vista.
• Rápido de configurar: configuración por ficheros casi autoexplicativos. Se pueden definir

varios entornos de configuración distintos (desarrollo, pruebas y producción).
• Rápido: está considerado uno de los frameworks más rápidos.
• URL amigables: proporciona una serie de librerías para permitir "urls amigables".
• Validación de formularios: incluye una librería de validación de formularios mediante reglas.
• Seguridad: incorpora una capa de seguridad y funciones para el filtrado XSS.
• Caché: posibilidad de cachear partes o páginas enteras de nuestra aplicación.
• Gestión de sesiones: reemplaza las sesiones nativas de PHP para proporcionar nuevas
funcionalidades
3.4.2. Symfony
Symfony está desarrollado por SensioLabs y programado íntegramente en PHP 5.3. Implementa el
modelo MVC y soporta la mayoría de gestores de bases de datos (Oracle, MySQL, PostgreSQL y
SQL Server). Su primera versión se lanzó en 2.007
Características:
• Fácil de instalar y configurar: configuración por ficheros.
• Independiente del gestor de BBDD: Incorpora una capa de abstracción de acceso a base
de datos que permite cambiar con facilidad de SGBD en cualquier fase del proyecto.
• Patrones: implementa un patrón propio de MVC con las variantes del uso de una capa de
abstracción a base de datos, el controlador frontal y las acciones. También implementa las
características de la POO como los espacios de nombres (por lo que es obligatorio el uso
de PHP 5.3).
• Línea de comandos: incluye herramientas por línea de comandos que facilitan generación
de código, lo cual contribuye a ahorrar tiempo de trabajo.
• Plantillas: incorpora el uso de plantillas a la capa Vista para facilitar el trabajo a los
diseñadores.
• Validación de formularios: soporta la validación automática de formularios.
• Caché: permite reducir el uso de banda ancha y la carga del servidor.
• URL amigables: gestión de enrutamientos y uso de "urls amigables".
3.4.3. Laravel
Taylor Otwell comenzó el desarrollo de Laravel como un intento de proporcionar a CodeIgniter

ciertas características que no incorporaba como el soporte a la autenticación y autorización de
usuarios. La primera versión se liberó en 2.011
Principales características:
• Modularidad: permite la extensión mediante la agregación de paquetes desde su directorio

Packalyst (http://packalyst.com/).
• Enrutamiento: su sistema de enrutamiento es muy sencillo y proporciona “urls amigables”.
• Seguridad: incorpora filtros para XSS y otras medidas de seguridad. También incluye
seguridad openSSL y cifrado AES-256-CBC.
• Caché: incluye un sistema de caché configurable.
• Autenticación: implemente de manera nativa un sistema de autenticación de usuarios.
Referencias
En septiembre de 2.016
(1) Un lenguaje interpretado no se compila ni genera un programa ejecutable. El fichero fuente es

leído por un interprete que lo ejecuta instrucción por instrucción.
(2) Fuente http://php.net/manual/es/language.operators.precedence.php
(3) Se puede definir como indexación la forma de acceder a cada uno de los valores del array.
(4) El Modelo-Vista-Controlador (MVC) es un patrón de arquitectura software de tres componentes:
• Modelo: gestiona el acceso a la información (bases de datos, ficheros, …).
• Vista: gestiona la presentación de la información.
• Controlador: hace de “intermediario” entre el Modelo y la Vista, respondiendo a las

peticiones (eventos) del usuario.
MS.NET
Evjen, B., Hollis, B., Lhotka, R. y otros. (2004). Professional VB.NET 2003. Wrox Press.
Sharp, J. (2008). Visual C#. Anaya Multimedia.
Shepherd, G. (2008). ASP.NET 3.5. Anaya Multimedia.
Spaanjaars, I. (2014). Beginning ASP.NET 4.5.1: in C# and VB. Wrox Press.
Java
Cadenhead, R. (2012). Java 7. Anaya Multimedia.
Eckel, B. (2002). Piensa en Java. Pretince Hall.
Mankale, A. (2015). Mastering Spring Application Development. Packt Publishing.
Morelli, R., Walde, R. (2012). Java, Java, Java Object-Oriented Problem Solving. Trinity College.
Richardson, W., Avondolio, D., Schrager, S., Mitchell, M. y Scanlon, J. (2007). Professional Java.
Wrox Press.
Walls, C. (2011). Spring. Anaya Multimedia.
PHP
Boronczyk, T., Naramore, E., Gerner, J. y otros. (2009). Desarrollo web con PHP 6, Apache y
MySQL. Anaya Multimedia.
Doyle, M. (2010). PHP Práctico. Anaya Multimedia.
Lecky-Thompson, E y Nowicki, S. (2009). Professional PHP6. Wrox Press.
Pecoraro, C. (2015). Mastering Laravel. Packt Publishing.
Salehi, S. (2016). Mastering Symfony. Packt Publishing.
Tema 30. Herramientas de generación de código
gvNIX y gvHIDRA
Matías Jiménez Jiménez

Colegiado 0512
La evolución en las tecnologías es constante, hemos pasado de tarjetas perforadas a

código binario, de código binario a lenguaje ensamblador y posteriormente a lenguajes
de alto nivel. El paso hacia código autogenerado era de esperar, su entrada en los
sistemas de información y en el desarrollo de aplicaciones ha supuesto una revolución
tanto en la figura del programador, como en la productividad a la hora de desarrollar
una solución. La importancia de su existencia y su buen uso hace que la parte de
desarrollo alcance otra dimensión. ¿Qué será lo próximo? ¿Codificación por voz?
Todo es posible.
1. Empezando con gvHIDRA
1.1. ¿Qué es gvHIDRA?
gvHidra son las iniciales de Generalitat Valenciana: Herramienta Integral de Desarrollo Rápido de
Aplicaciones.
Si hay que dar una explicación rápida de qué es este proyecto, podemos decir que se trata de un
entorno de trabajo (framework) para el desarrollo de aplicaciones de gestión en entornos web con
PHP siguiendo una guía de estilo (una guía para unificar los criterios de aspecto y usabilidad en el
proceso de desarrollo de aplicaciones).
Evidentemente, esto no responde de forma plena a la pregunta que da título a este punto. Por ello,
vamos a explicar las motivaciones que llevaron a su creación y las características más importantes
que cubre.
A continuación se explica con más detalle:
• Patrones de interfaz.
Una de las tareas más costosas es en la definición de la interfaz con el usuario. Para facilitar el
trabajo, se han definido una serie de patrones de básicos. Estos patrones definen la forma de
representación de la información (formato tabular, registro,…) y la forma con la que
interacciona el usuario con dicha información. Esto nos lleva a que con la selección de un
patrón obtenemos el diseño global de la ventana.
Figura 1. Ejemplos de patrón simple tabular, maestro detalle y árbol
gvHIDRA y gvNIX
• Componentes complejos.
La experiencia acumulada nos dice que todas las aplicaciones necesitan de una serie de
componentes “complejos”. Ventanas de selección (en PowerBuilder listas de valores), listas
enlazadas, acciones de interfaz (en WEB tec. AJAX), mensajes de información,… El framework
genera estos componentes simplificando su utilización en las aplicaciones.
Figura 2. Componentes generados
• Operaciones preprogramadas y parametrizables.
Al igual que con los componentes, hemos advertido que cierta problemática se repite en todas
las aplicaciones que desarrollamos. Por esa razón, la hemos generalizado y resuelto en el
framework, siendo incorporada a las aplicaciones de forma transparente. Algunos ejemplos
son:
Control de acceso concurrente: es importante que el garantizar la integridad de los

cambios realizados por ello el framework incorpora de forma transparente un
mecanismo de control.
CRUD: el framework genera las sentencias SQL necesarias para Crear, Leer,
Actualizar y Borrar un registro.
Persistencia y validación de tipos: completando lo que nos ofrece el PHP, el framework

incorpora objetos persistentes y validación de tipos de datos.
• Soporte a diferentes SGBD.
A través del proyecto PEAR::MDB2, el framework permite trabajar con diversos SGBD.
Además, incorpora un capa de intermedia propia del framework que nos permite
independizarnos de las diferentes interpretaciones del SQL que hace cada gestor (definición de
límites, transacciones,…).
• Listados e informes.
Uno de los mayores retos que hemos encontrado en el ámbito del proyecto fue generar
informes de forma tan versátil como los datawindows de PowerBuilder. Gracias al proyecto
jasperreports lo hemos conseguido. Apoyados por herramientas como el iReport, conseguimos
listados e informes muy completos y en diferentes formatos.
• Arquitectura MVC.
El framework garantiza la arquitectura MVC en todos nuestros desarrollos forzando la

separación de la lógica de negocio de la presentación mediante la distribución física de los
ficheros fija.
• Control de la vista.
Como hemos comentado, uno de los objetivos principales de la herramienta es simplificar la

labor del programador. Con esta premisa, hemos conseguido que un desarrollador de
gvHIDRA realice una aplicación WEB sin necesidad de introducir ninguna línea de HTML o
Javascript. La idea es que centre su trabajo únicamente en PHP, siendo así mucho más
productivo.
• Custom y temas.
La herramienta está pensada para su despliegue en diferentes organizaciones, por ello, se

distribuye en una arquitectura App/Custom/Core que permite modificar tanto el aspectos (CSS,
imágenes,...) como definir comportamientos propios de la organización.
• Testing.
Incorpora la herramienta PHPUnit para que se puedan realizar testeos sobre el código
generado. También se incorporan consejos y reglas para poder realizar test automáticos con
Selenium.
• Autentificación, auditoría y depuración.
Para poder integrarse en diferentes organismos incorpora un mecanismo de validación

extensible, siendo capaz de acoplarse a cualquier sistema de validación a través de PHP.
Dispone de herramientas para realizar auditorías y depuración.
Como buen proyecto opensource, el proyecto siguen en constante evolución incorporando nuevas
funcionalidades que nos permitan, ante todo, ser más productivos.
1.2. Arquitectura
En este capítulo vamos a ver algunos conceptos teóricos que son necesarios para entender cómo
funciona este framework.
gvHIDRA y gvNIX
Se verán conceptos relativos a la arquitectura de las aplicaciones, a la interfaz con el usuario y a la

lógica de negocio.
gvHIDRA, como se ha comentado, es un proyecto opensource que se ha desarrollado para poder

ser desplegado en entornos heterogéneos. Para ello su configuración interna se ha organizado en
una estructura de capas que permite redefinir los parámetros, crear clases específicas o cambiar el
aspecto de cada una de nuestras aplicaciones.
1.2.1. Arquitectura por capas
Concretamente, el framework ofrece tres capas:
Figura 3. Arquitectura por Capas
1. Core: es la capa propia de los ficheros del framework. Está ubicada en el directorio igep y
contiene ficheros de configuración propios del proyecto.
2. Custom: destinado a las configuraciones propias de la entidad donde se despliega la

aplicación. Generalmente, la organización donde se despliegue una aplicación tiene una
serie de características propias:
aspecto: se puede configurar a partir de css e imágenes.
definición de listas o ventanas de selección generales (municipios, provincias,

terceros,...).
clases propias, tipos, ws,...
configuraciones propias: conexiones a BBDD corporativas, acceso a datos comunes,

formato de las fechas,...
3. App: cada aplicación tiene una configuración propia:
acceso a la BBDD propios de la aplicación.
listas y ventanas de selección propias de la aplicación.
configuraciones propias de la aplicación: nombre aplicación, versión, modo de

debug/auditoria, comportamiento de la búsqueda,...
Resumiendo, debemos tener en cuenta que hay varios niveles dentro de la arquitectura de una
aplicación gvHIDRA y que en aras de la reutilización, conviene definir un custom propio de la
organización en la que nos encontramos.
1.2.2. Configuración
En cuanto a la carga de la configuración, el framework la realiza en dos fases consecutivas

siguiendo en cada una de ellas el orden (core/custom/app). Las dos fases se corresponden con:
• carga estática: esta fase carga los parámetros que estén ubicados en el fichero de
configuración gvHidraConfig.inc.xml . Tenemos un fichero de este tipo en cada una de las
capas, se cargarán en este orden:
igep/gvHidraConfig.inc.xml: fichero de configuración propio del framework. No debe ser

modificado ya que contiene los parámetros propios del framework.
igep/custom/xxx/gvHidraConfig.inc.xml: fichero de configuración de la organización.

Aquí se definirán las configuraciones propias de la organización.
gvHidraConfig.inc.xml:fichero de configuración propio de la aplicación.
• carga dinámica: esta fase, se realiza una vez acabada la anterior, con lo que machacará
las configuraciones que se hayan realizado. Puede ser muy útil para fijar configuraciones
de forma dinámica (dependiendo del entorno de trabajo), pero es peligroso, ya que puede
ser difícil depurar un error. Los ficheros por capa se ejecutarán en el siguiente orden:
gep/actions/gvHidraMainWindow.php: fija la configuración dinámica del framework. No

debe ser modificado.
igep/custom/xxx/ actions/CustomMainWindow.php: fija la configuración dinámica de la

organización.En este fichero se deben definir las listas y ventanas de selección de la
organización.
actions/principal/AppMainWindow.php: fija la configuración dinámica de la aplicación.

En este fichero se deben definir las listas y ventanas de selección propias de la
aplicación.
1.3. Aspecto Visual
Vamos a entender la anatomía de una ventana gvHidra:
gvHIDRA y gvNIX
Figura 4. Partes de la ventana de gvHidra
Una ventana de gvHidra está dividida en 4 secciones:
• Barra superior (1).
En esta barra aparece alineado a la izquierda el título de la ventana, y, alineado a la derecha

aparecerán, si los hay, botones tooltip. Botones tooltip son botones que efectúan acciones
relacionadas con la interfaz.
• Contenedor (2).
Donde se ubicará el formulario con los datos y campos con los que trabajaremos.
• Barra inferior (3).
En ella, alineado a la izquierda, se ubicará el paginador y, alineados a la derecha aparecerán

los botones.
• Contenedor de pestañas (4).
En esta zona irán apareciendo pestañas con las que podremos cambiar el modo de trabajo
(búsqueda, listado, registro,...).
1.3.1. Modos de trabajo y ventanas gvHidra
La forma de trabajar con las ventanas gvHidra se ha clasificado por modos de trabajo. Definiendo
modo de trabajo como la forma de representación de la información con la que vamos a trabajar.
Estos modos de trabajo se verán reflejados tanto en la zona Contenedor (2) del panel como en la
de Contenedor de pestañas (4), la pestaña nos indicará el modo activo.
Los modos que tenemos son tres que se corresponden con las pestañas:
1. Búsqueda o filtro.
2. Tabular o listado.
3. Registro o edición.
Partiendo de todo lo comentado, tenemos dos formas de trabajar en gvHidra:
1. Dos modos de trabajo.
Con esto nos referimos al flujo de trabajo. En este caso partimos de una búsqueda y el resultado
se muestra en una tabla o ficha, donde los datos ya son accesibles y se podrá operar sobre ellos.
Figura 5. Ej. Modo búsqueda/tabla
Figura 6. Ej. Modo búsqueda/ficha
2. Tres modos de trabajo.
En este caso es una combinación de los dos anteriores. Se parte de un panel de búsqueda. El
resultado de dicha búsqueda se mostrará en un panel tabular, con la peculiaridad de que en este
caso solamente se podrá efectuar el borrado de las tuplas que se seleccionen. Para inserción o
modificación se pasa a un panel modo ficha.
gvHIDRA y gvNIX
Figura 7. Ej. Modo búsqueda/tabla/ficha
1.4. Lógica de Negocio
1.4.1. Acciones y Operaciones
Acciones y operaciones son dos conceptos fundamentales que hay que conocer para desarrollar
con el framework.
Una acción es el proceso que se inicia tras la solicitud de un usuario (un estímulo de la IU). Las
acciones están divididas en dos grupos:
1. Acciones genéricas: Las acciones genéricas resuelven procesos comunes de un

mantenimiento (altas, bajas, modificaciones, búsquedas,...).
2. Acciones particulares: Con las acciones particulares se podrán resolver necesidades

concretas no resueltas por el framework.
Las operaciones son métodos internos del framework que serán llamados para cumplir lo que cada
acción requiere. Algunas de estas operaciones son públicas por lo tanto el programador podrá
invocarlas desde las acciones particulares. El programador podrá modificar el comportamiento de
por defecto de la operación sobreescribiendo con una serie de métodos abstractos (virtuales).
La siguiente imagen ilustra cómo se produce la comunicación entre las diferentes capas desde que
un estímulo es recibido en la interfaz hasta que se resuelve. Podemos ver claramente la diferencia
esencial entre acciones y operaciones.
Figura 8. Acciones y Operaciones
Vamos a explicar un poco más en profundidad cada una de las acciones genéricas. Explicando
tanto el objetivo global de la acción, los posibles retornos que produce, las operaciones que los
componen y los métodos virtuales de cada una de estas operaciones.
Tabla I. Conceptos comunes a todas las acciones genéricas

Métodos virtuales: Todas las acciones genéricas tienen una serie de métodos que el programador
puede sobreescribir completando el comportamiento de la acción. Generalmente hay un método
virtual “pre”, antes de la acción (inserción, modificación, borrado), y un método “post”, después de
la acción.
actionForward: Acción de retorno de un método virtual. Puede tomar un valor por defecto
asignado por el framework o el programador asignarle uno particular.
gvHIDRA y gvNIX
Tabla II. Valores de retorno de los métodos virtuales

• 0: Correcto, la ejecución continúa. En este caso el actionForward se corresponde con la acción
gvHidraSuccess.
• -1: Ha habido un problema, el framework lanza un error si es problema interno de él, en cambio,
si es un problema particular de la aplicación, se ha de capturar el error y lanzar un mensaje propio
(instrucción: $this->showMessage('xxx');) No se recargará la ventana. En este caso el
actionForward se corresponde con la acción gvHidraError.
• actionForward: Acción de retorno programada por el desarrollador para saltarse la ejecución de
por defecto, provoca una recarga de la ventana. Común a todas las acciones genéricas salvo a la
de Recargar, esta acción no contempla una acción de retorno particular
1.4.2. Acciones genéricas
1. Iniciar ventana.
Esta acción se ejecutará al iniciar la ventana.
La acción contiene la siguiente operación:
• initWindow: Genera todas las listas definidas para el panel y las carga en el objeto
v_datosPreinsertar. Almacena el valor del módulo actual por si es la primera vez que se
entra en una pantalla de dicho módulo. Su comportamiento se puede sobrecargar con el
método virtual preIniciarVentana.
preIniciarVentana: Método que permite realizar cualquier acción antes de que se

cargue la ventana.
2. Buscar.
Realiza la consulta del panel basándose en los datos que hay en el panel filtro.
La acción se compone de dos operaciones:
• buildQuery: Método privado que recoge los datos del panel filtro y los añade al WHERE de
la consulta del panel. Su comportamiento se puede sobrecargar con en el método virtual
preBuscar.
preBuscar: Método que permite realizar cualquier acción antes de que se realice la
consulta.
• refreshSearch: Método público que se encarga de realizar la consulta que se ha generado

con el método anterior. Es importante saber, también, que este método puede ser llamado
en cualquier momento para refrescar los datos de un panel, por ejemplo, después de una
acción particular. Su comportamiento se puede sobrecargar con el método virtual
postBuscar.
postBuscar: Método que permite modificar los resultados obtenidos en la búsqueda. En

el caso de que este método devuelva un 0 existe la posibilidad de tener un
actionForward con la acción gvHidraNoData que mostrará un mensaje avisando que la
consulta no ha devuelto datos, si se quiere particularizar este caso se sobrecargará la
acción.
Para los patrones simples Tabular-Registro, existe la posibilidad de añadir el actionForward

con la acción gvHidraSuccessOne que permite agilizar el uso de la ventana cuando la
búsqueda devuelve único registro pasando directamente al modo edición. Se ejecutarán los
mismos métodos que al editar un registro.
3. Editar.
Esta acción genérica se ejecuta cuando estamos trabajando con tres modos. Como su propio
nombre indica realiza la consulta de edición a partir de los datos seleccionados en el panel
tabular.
• buildQueryEdit: Método privado que recoge los datos del panel tabular con los que formará
la WHERE de la consulta que nos devolverá los datos que se podrán editar. Su
comportamiento se puede sobrecargar con el método virtual preEditar.
preEditar: Método que permite realizar cualquier acción antes de que se realice la consulta
de edición.
• refreshEdit: Método público que se encarga de realizar la consulta que se ha generado con
el método anterior, así obtener los datos actualizados. Es importante saber, también, que
este método puede ser llamado en cualquier momento para refrescar los datos de un
panel, por ejemplo, después de una acción particular. Su comportamiento se puede
sobrecargar con el método virtual postEditar.
• postEditar: Método que permite modificar los resultados obtenidos de la consulta.
En el caso de que no se haya seleccionado ninguna tupla para editar, aparecerá un mensaje
por defecto informándonos de la situación. Para poder sobrecargar este comportamiento existe
un actionForward con la acción gvHidraNoData con el que podremos hacerlo.
4. Recargar.
Acción genérica que actúa en un patrón maestro-detalle. Se ejecutará cuando se efectúe un

cambio de maestro, recargará los detalles correspondientes.
gvHIDRA y gvNIX
• buildQueryDetails: Crea/recupera la instancia del panel detalle activo (puede haber N

detalles activos). Llama al método refreshDetail de esa instancia detalle. Su
comportamiento se puede sobrecargar con el método virtual preRecargar.
preRecargar: Método que permite realizar cualquier acción antes de efectuar la consulta
del detalle.
• refreshDetail: Método público que se encarga de realizar la consulta que se ha generado

en el método anterior, obtener los datos del detalle a partir del maestro seleccionado. Su
comportamiento se puede sobrecargar con el método virtual postRecargar. Es importante
tener en cuenta que el programador puede llamar a este método en cualquier momento
para refrescar los datos de un detalle, por ejemplo, después de una acción particular.
postRecargar: Método que permite modificar los datos obtenidos de la consulta.
Hay que recordar que los métodos virtuales de esta acción no tienen como retorno un
actionForward programado por el desarrollador.
5. Modificar.
Esta acción genérica se ejecuta desde el modo de trabajo edición, cuando, tras haber editado
unas tuplas, se pulsa el botón guardar.
• updateSelected: Método privado que recoge los datos de pantalla y actualiza en la BD los
datos modificados. Su comportamiento se puede sobrecargar con el método virtual
preModificar.
preModificar: Método que permite realizar cualquier acción antes de que se lleve a cabo la
modificación.
• refreshEdit: Método público que se encarga de actualizar los datos visualizados en el modo
de trabajo edición. Su comportamiento se puede sobrecargar con el método virtual
postModificar.
postModificar: Método que permite utilizar los datos modificados en otras operaciones.
• refreshSearch o refreshDetail: Método público que se encarga de actualizar los datos

después de la operación de actualización en el panel. Es importante tener en cuenta que
esto implica que se lanzará el postBuscar o el postRecargar.
La acción modificar por defecto deja el foco en el modo edición, este comportamiento se puede
cambiar. El cambio se realiza en el fichero mappings.php, en la entrada correspondiente a
modificar, en la acción gvHidraSuccess, cambiar en la url el panel destino (p. ej. panel=listado)
6. Borrar
Esta acción genérica se dispara “típicamente” desde el modo de trabajo tabular para eliminar
las tuplas seleccionadas.
• deleteSelected: Recoge las tuplas seleccionadas del panel y las elimina. Esta operación se
puede parametrizar haciendo uso de los métodos virtuales preBorrar y postBorrar.
preBorrar: Método que permite realizar cualquier acción antes de que se lleve a cabo el
borrado.
postBorrar: Método que permite modificar los resultados obtenidos después del borrado.

7. Insertar
Esta acción genérica se dispara desde el modo de trabajo inserción cuando, tras haber
introducido los datos, se pulsa el botón guardar.
• insertData: Recoge los datos de la pantalla y los inserta en la BD. Esta operación se puede
parametrizar haciendo uso de los métodos virtuales preInsertar y postInsertar.
preInsertar: Método que permite realizar cualquier acción antes de que se lleve a cabo la
inserción.
postInsertar: Método que permite utilizar los datos modificados en otras operaciones.

8. Nuevo
Esta acción genérica se invoca para preparar la presentación de datos en pantalla antes de
una inserción.
La acción se compone de la siguiente operación:
• nuevo: Realizará las operaciones de preparación de los datos y visualización previos a la

inserción. Esta operación se puede sobreescribir con el método virtual preNuevo.
gvHIDRA y gvNIX
preNuevo: Método que permite sobrecargar la acción nuevo antes de ser lanzada. Por
ejemplo, cuando tenemos algún campo que tiene un valor por defecto o es calculado a
partir de los valores de otros campos.
1.5. Elementos de gvHidra
gvHIDRA, aparte de proporcionar un core (igep) en el que se encuentran todas las funcionalidades
extensibles del framework, proporciona una estructura inicial de proyecto. Para empezar cualquier
aplicación con la herramienta, debemos bajar la plantilla inicial de proyecto correspondiente a la
versión con la que vamos a trabajar. Esta plantilla se encuentra en el paquete de la propia versión
en la ubicación plantilla-gvHidra.zip. Antes de descomprimir hay que advertir que los ficheros están
codificados en ISO-8859-1 o ISO-8859-15, por lo que hay que tener precaución con usar algún
editor que respete estas codificaciones.
En el interior de la plantilla, encontramos una estructura básica de aplicación a partir de la cual

construiremos nuestra aplicación. De esta estructura destacamos:
• gvHidraConfig.inc.xml: donde añadir las conexiones a bases de datos, código de la

aplicación y versión,...
• actions/principal/AppMainWindow.php: donde añadiremos las listas y ventanas de

selección particulares, log,...
• mensajes.php: donde añadir mensajes particulares de la aplicación.
• include/menuModulos.xml: define el menu principal de la aplicación. Hay que modificarlo

con las acciones propias de la aplicación. También podemos usar ciertas opciones
predefinidas.
• include/menuAdministracion.xml: definimos opciones de la 2ª columna de la pantalla

principal. Siguen las mismas normas que en menuModulos.xml.
• include/menuHerramientas.xml: definimos opciones de la 3ª columna de la pantalla

principal. Siguen las mismas normas que en menuModulos.xml.
• include/include.php: donde, conforme vayamos creando clases de negocio las iremos

incluyendo. Los includes de ficheros "action/*" se pueden borrar.
• include/mappings.php: en la función ComponentesMap, excepto la llamada al constructor

del padre, todo se puede borrar.
• templates_c: directorio de compilación de plantillas. El usuario web tiene que tener

permisos de escritura.
A esta estructura tenemos que añadirle el core del framework correspondiente (directorio igep) que
también se distribuye con la versión de gvHIDRA.
1.6. Fuentes de Datos
Una de las características importantes que tenemos en PHP es la gran cantidad de distintos tipos
de bases de datos soportados. Cada una de ellas requiere de una extensión que define su propia
API para realizar la misma tarea, desde establecer una conexión hasta usar sentencias preparadas
o control de errores. Cambiar las llamadas a la API cuando cambiamos de BD en una aplicación es
costoso pero se puede hacer, aunque en el caso de un framework no es factible porque tiene que
funcionar el mismo código con varias BD.
Lo que se suele hacer es añadir una capa de abstracción que nos permita operar de la misma
manera con todos los tipos de BD (al menos para las operaciones más habituales o las más
estandarizadas). En el caso de gvHIDRA se utiliza la librería MDB2 de PEAR
(http://pear.php.net/package/MDB2/), una de las más usadas para este fin gracias a su amplia
funcionalidad y a la actividad del proyecto. De esta forma podemos usar una BD sin preocuparnos
por el tipo, ya que tenemos una API única.
Sin embargo, a pesar de usar la capa de abstracción, sigue habiendo aspectos que dependen del
tipo de BD: uso de características especiales (secuencias, limit, bloqueos,...), manejo de
transacciones, representación de fechas y números,... Para resolver estos problemas, definimos en
el framework otra capa de abstracción (que se implementa en unas clases que se ven en el
apartado siguiente) y las funciones más importantes que realizan son:
• Definición del formato de fechas y números que se va a usar para comunicarse con el
gestor de BD. Este formato es transparente para el programador, ya que es el framework el
que hace las conversiones necesarias cuando enviamos/recogemos información a/de la
BD. Normalmente nos referiremos a éste como formato de BD.
• Inicialización de la conexión: son operaciones que se hacen cada vez que se hace una
nueva conexión. Por ejemplo se fija la codificación que se va a usar en la comunicación
(actualmente LATIN1 o ISO-8859-1, que es la usada en el framework), o se modifican
parámetros de la conexión para establecer el formato de BD.
• Ajustes por sintaxis: aquí se incluyen una serie de métodos para obtener la sintaxis de
ciertas operaciones que se pueden comportar de forma distinta en cada BD. Por ejemplo la
clausula limit (para paginar resultados de consultas), función para concatenar cadenas, uso
de secuencias,...
• Unificar tratamiento de errores: por ejemplo, cuando hay un registro bloqueado, poderlo
detectar independientemente de la BD.
Actualmente las BD soportadas por gvHIDRA son postgresql, mysql y oracle.
gvHIDRA y gvNIX
1.7. Seguridad
gvHIDRA permite integrar las aplicaciones con diferentes sistemas de autentificación e, incluso,
permite crear uno específico para nuestra aplicación. Internamente utiliza PEAR::Auth
[http://pear.php.net/manual/en/package.authentication.auth.php], por lo que en algunos puntos es
conveniente ver su documentación.
A partir de la versión de gvHidra 4.1 se ha integrado el proyecto PEAR Auth dentro del núcleo por
lo que ya no se necesitará tener instalado en nuestro servidor el paquete Auth. Para comprender el
funcionamiento, conviene distinguir dos partes:
1. Autentificación: validar que el usuario es quien dice ser. El framework proporciona para tal
efecto un formulario para introducir las credenciales y unos métodos para la comprobación
de su validez.
2. Autorización: carga de la información relativa al usuario / aplicación. Esta información se

carga en la sesión, y su estructura puede verse en los ejemplos del método postLogin en
igep/include/valida/AuthBasic.php, igep/custom/cit.gva.es/auth/AuthWS.php y en
Autenticación imap gva
[http://zope.coput.gva.es/proyectos/igep/trabajo/igep/auth_gva.html].
1.7.1. Módulos y Roles
1.7.2. Módulos
Los módulos representan permisos que un usuario tiene en una aplicación determinada. Los
módulos se asignan cuando se lleva a cabo una asociación entre un usuario y una aplicación, y se
cargan en el inicio de la aplicación. Cada módulo tiene un código, una descripción y opcionalmente
puede tener un valor.
Cada usuario puede tener asignado uno o varios módulos, y para cada uno puede modificar su
valor. Algunos usos habituales de módulos son el controlar si un usuario puede acceder a una
opción de menú, o si puede ver/editar un campo determinado de una pantalla, o para guardar
alguna información necesaria para la aplicación (departamento del usuario, año de la
contabilidad,...). También suelen usarse para definir variables globales para todos los usuarios,
aunque en este caso es recomendable asignarlos a roles (ver apartado siguiente).
Ejemplo:
Todos los usuarios que consulten la aplicación PRESUPUESTARIO deben tener el módulo
M_CONSUL_PRESUPUESTARIO, es decir, nadie que no tenga ese módulo asociado podrá
acceder al apartado de listados de la aplicación.
Sólo el personal de la oficina presupuestaria tendrá acceso a la manipulación de datos, es decir el

módulo M_MANT_PRESUPUESTARIO
Sólo técnicos y el jefe de la oficina presupuestaria tendrán acceso a la entrada de menú "control de
crédito". Pues serán aquellos usuarios que tengan el módulo M_MANT_PRESUPUESTARIO, con
el valor TECNICO o el valor JEFE.
Usuarios:
Sandra (Administrativa de otro departamento que consulta la aplicación): Tiene el módulo

M_CONSUL_PRESUPUESTARIO
Juan (Administrativo): Tiene el módulo M_MANT_PRESUPUESTARIO, (bien sin valor, o con el

valor PERFIL_ADMD)
Pepe (Técnico): Tiene el módulo M_MANT_PRESUPUESTARIO con valor PERFIL_TECNICO
Pilar (Jefa de la oficina presupuestaria): Tiene el módulo M_MANT_PRESUPUESTARIO con valor

PERFIL_JEFE
Módulos:
Nombre: M_CONSUL_PRESUPUESTARIO
Descripción: Módulos de acceso a las consultas de la aplicación de presupuestario.
Valores posibles: <COMPLETAR>
Nombre: M_MANT_PRESUPUESTARIO
Descripción: Módulos de acceso a las opciones de mantenimiento de la aplicación de

presupuestario.
Valores posibles: PERFIL_ADMD, PERFIL_TECNICO o PERFIL_JEFE
1.7.3. Roles
Los roles representan el papel que el usuario desempeña en una aplicación y a diferencia de los
módulos, cada usuario sólo puede tener uno y no tienen valor. ¿Entonces para qué queremos los
roles si podemos hacer lo mismo usando módulos sin valor? Podemos ver los módulos como los
gvHIDRA y gvNIX
permisos básicos, y los roles como agrupaciones de módulos. Realmente los roles se utilizan para
facilitar la gestión de usuarios.
Si sólo usamos módulos, y por ejemplo tuviéramos 30 módulos, sería muy difícil clasificar a los
usuarios, ya que seguramente cada uno tendría una combinación distinta de módulos. Y cada vez
que hubiera que dar de alta un usuario tendríamos que tener un criterio claro para saber cuáles de
los módulos asignar. Con roles es más simple, ya que es sencillo ver los permisos de cualquier
usuario (viendo el role suele ser suficiente), y para añadir nuevos usuarios normalmente solo
necesitaremos saber su role. Para que esto sea fácil de gestionar, tendríamos que tener algún
mecanismo que nos permitiera asignar módulos a roles, y que los usuarios con un role "heredaran"
estos módulos. Lo más flexible seria tener esta información en tablas aunque también se podría
empezar haciéndolo directamente en PHP. De esta forma, añadir un nuevo usuario de tipo
administrador consistiría simplemente en indicar su role, en vez de tener que asignarle los N
módulos que tienen los administradores.
La solución más flexible seria usar sólo módulos para controlar cualquier característica que pueda
ser configurable por usuario, y asignar los módulos a los roles de forma centralizada (bien en base
de datos o en el inicio de la aplicación). De esta forma el programador solo tendría que tratar con
los módulos, y el analista con los módulos de cada role.
El ejemplo anterior usando roles podría ser:
Módulos: M_CONSUL_PRESUPUESTARIO, M_MANT_PRESUPUESTARIO (ambos sin valor).
roles:
PERFIL_ADMD (módulo M_MANT_PRESUPUESTARIO), asignado a Juan.
PERFIL_TECNICO (módulo M_MANT_PRESUPUESTARIO), asignado a Pepe.
PERFIL_JEFE (módulo M_MANT_PRESUPUESTARIO), asignado a Pilar.
PERFIL_OTROS (módulo M_CONSUL_PRESUPUESTARIO), asignado a Sandra.
En este caso las dos soluciones tienen una complejidad similar, aunque las diferencias serán más
evidentes conforme aumenten el número de módulos y usuarios. Si por ejemplo decidiéramos que
ahora todos los técnicos han de tener un nuevo módulo X, sin usar roles tendríamos que añadir
ese módulo a todos los usuarios que tuvieran el módulo M_MANT_PRESUPUESTARIO con valor
PERFIL_TECNICO; usando roles seria simplemente añadir el módulo X al role PERFIL_TECNICO.
2. gvNIX
gvNIX es un entorno de trabajo Java de código abierto para el desarrollo rápido de aplicaciones
web altamente productivo, flexible y que no compromete la calidad de los proyectos.
gvNIX trabaja sobre la herramienta de desarrollo Spring Roo ampliando sus funcionalidades
básicas con componentes de alto nivel funcional.
gvNIX está patrocinado por la Dirección General de Tecnologías de la Información y la

Comunicación (DGTIC) de la Conselleria de Hacienda y Modelo Económico de la Generalitat
Valenciana (Comunidad Valenciana, España), gestionado por la Asociación gvSIG y dirigido por
DISID. gvNIX se consolida como estándar para desarrollo Java de la DGTIC de la Generalitat
Valenciana.
gvNIX está disponible dentro del proyecto de Migración a Software de fuentes abiertas gvPONTIS.
gvNIX es un entorno de trabajo Java de código abierto para el desarrollo rápido de aplicaciones
web sobre tecnología Spring. Sus funcionalidades hacen que sea un entorno altamente productivo,
flexible y que no compromete la calidad de los proyectos.
Está compuesto por una serie de herramientas de código abierto distribuidas en forma de "Spring
Roo Add-On Suite" a través de un repositorio OSGi R5. Esto le proporciona un amplio apoyo por
parte de importantes organizaciones como Spring y Pivotal. Añade funcionalidades de alto nivel a
las prestaciones que ya se obtienen con Spring Roo para mejorar la productividad.
2.1. ¿Qué es Spring Roo?
Spring Roo es un entorno de trabajo Java que permite el desarrollo de aplicaciones web de forma
rápida y cómoda para el desarrollador. Sus principales características son:
• Generación de código en Java (lenguaje estático).
• Eliminar el trabajo tedioso centrando el desarrollo en la lógica de negocio.
• Convención sobre configuración.
• Desarrollo dirigido por el dominio (Domain-Driven Development):
Diseño dirigido por el modelo de entidades.
Lógica en las entidades (Real Object Oriented), eliminando capas redundantes.
Otras capas opcionales (servicios, DAOs,…).
gvHIDRA y gvNIX
• Crea un proyecto en segundos.
• Realimentación: añade valor durante todo el ciclo de vida.
• No incorpora elementos adicionales al entorno de ejecución, por lo que no penaliza la

velocidad ni la memoria de la aplicación.
• Recibe instrucciones a través de una consola interactiva con autocompletado y ayuda en

línea.
• Extensible usando bundles OSGi.
• Aprovecha el conocimiento: no necesita más conocimiento que el necesario para el

desarrollo de aplicaciones JEE.
2.2. ¿Qué es un "Roo Add-On Suite"?
Los "Roo Add-On Suites" son la mejor manera de empaquetar y distribuir conjuntos de Add-Ons
para que puedan ser instalados en distribuciones de Spring Roo de forma rápida y sencilla.
Están basados en subsistemas de OSGi R5, los cuales permiten instalar un conjunto de
componentes sobre la distribución de Spring Roo sin comprometer su modularidad.
Por todo lo anterior, decimos que gvNIX es un "Spring Roo Add-On Suite" que puede ser instalado
en distribuciones de Spring Roo para ampliar sus funcionalidades básicas.
2.3. ¿Qué ofrece gvNIX?
gvNIX aprovecha las características de Spring Roo y aporta su propia filosofía, ofrecer al
desarrollador componentes de alto valor funcional para aplicaciones corporativas:
• Control de concurrencia a nivel de aplicación sin campos en base de datos.
• Utilidades de generación de consultas.
• Utilidades de modificaciones múltiples de entidades.
• Gestión de temas visuales utilizando jQuery, Bootstrap, HTML5 y CSS3.
• Gestión de la visualización de excepciones.
• Gestión de mensajes de usuario en ventana modal.
• Gestión de la estructura de páginas en el menú.
• Gestión de patrones de visualización de entidades y sus relaciones utilizando el

componente Datatables.
• Gestión de transformación de cadenas vacías a valores nulos.
• Gestión de servicios locales y servicios web (importación y exposición).
• Control de acceso (autenticación y autorización).
• Gestión de configuraciones por entorno.
• Generación de documentos (reportes).
• Gestión de relaciones utilizando componente Lupa.
• Gestión de información geográfica.
• Generación de GeoPortales interactivos.
2.4. Empezando con gvNIX:
En este capítulo se explicará brevemente como generaremos una aplicación sencilla paso a paso
de forma rápida para que puedas ver y entender cómo se trabaja con la herramienta de desarrollo
gvNIX en un proyecto básico.
Los detalles sobre la generación del código y la explicación de cada uno de los comandos
ejecutados, se detallan en el manual donde podrás consultarlo.
2.4.1. ¿Qué aprenderás?
En la guía se podrá aprender cómo crear una aplicación desde cero utilizando la herramienta de
desarrollo gvNIX sobre el IDE STS.
Las principales características de gvNIX tanto en la guía, aquí las enumeramos, son las siguientes:
• Creación de un proyecto.
• Configuración de persistencia.
• Generación del modelo de entidades.
• Generación de métodos de búsqueda.
• Generación de capa web.
gvHIDRA y gvNIX
• Componente Datatables y Bootstrap.
• Patrones de Pantalla.
• Ejecución de una aplicación en un servidor Tomcat.
• Edición de datos en línea.
• Componente Lupa.
• Instalación y gestión de menú.
• Aplicar seguridad a nuestra aplicación.
• Generación de informes utilizando Jasper Reports.
• Tests funcionales y Tests de integración.
• Generación de servicios web.
2.4.2. Detalles de la aplicación
La aplicación que se va a generar está basada en la aplicación de ejemplo Petclinic de Spring. Los
usuarios de esta aplicación son empleados de una clínica veterinaria, que a lo largo de su jornada
laboral, necesitan gestionar información sobre veterinarios, clientes y sus mascotas.
Después de esta pequeña introducción sobre la aplicación que se va a desarrollar, hemos

generado un diagrama de clases simple para el modelo de entidades de esta aplicación:
Figura 9. Petclinic UML
Para sacar el máximo partido a las funcionalidades de gvNIX y Spring Roo, es recomendable que
las aplicaciones se generen siguiendo la filosofía del diseño guiado por el dominio.
Hay que tener en cuenta que la aplicación que se va a generar no será una aplicación real, ya que
normalmente necesitaría una serie de trabajos adicionales para personalizar la capa web,
implementar lógica de negocio, etc.
Los pasos siguientes los dejamos para una práctica in situ para la creación de un proyecto
mediante el framework y haciendo uso de la guía publicada en Internet.
2.5. Add-Ons de gvNIX
2.5.1. Add-on Web Menu
Sistema de gestión del menú web.
Este Add-on instala un nuevo sistema de gestión del menú web de la aplicación sobre la que se
está trabajando para facilitar la organización de su estructura de páginas y grupos.
gvHIDRA y gvNIX
Las principales características de este sistema son:
Modelo de datos del menú separado de su formato de visualización.
• El modelo de datos del menú no está ubicado en la misma página que lo visualiza como
ocurre en el modelo de menú que se proporciona por defecto. El modelo del menú estará
definido en un archivo XML independiente.
Múltiples niveles en el menú.
• Soporte para crear elementos jerarquizados con múltiples niveles. Permite añadir, mover y
anidar en varios niveles los elementos del menú.
Gestión de elementos desde consola.
• Permite añadir, quitar, mover, actualizar, definir permisos, ocultar, definir enlaces, etc. para
cada uno de los elementos del menú desde la consola del framework.
Integración con Spring Security.
• Si está instalado el sistema de seguridad, se puede establecer que ciertos elementos del
menú no sean visibles si el usuario no está entre los roles permitidos para ello.
Gestiona las peticiones de Roo.
• Aunque el sistema de gestión del menú es distinto al que se proporciona por defecto, este
nuevo sistema también gestiona las peticiones de generación de elementos del menú
realizadas por el resto de comandos. Es decir, si se encuentra instalada la nueva gestión
del menú y cualquier otro comando solicita crear o actualizar un elemento del menú, la
solicitud se realizará correctamente utilizando el nuevo sistema de gestión.
2.5.2. Add-on JPA
Add-on de utilidades enfocadas a la persistencia y consulta de las entidades.
Este add-on incluye las siguientes funcionalidades:
• Servicios de persistencia de entidades en bloque.
• Registro de información adicional para búsquedas por relaciones.
• Auditoría y registro de histórico de cambios de las entidades.
• Persistencia de entidades con campos de tipo geográfico.
• Para poder utilizar estas funcionalidades hay que ejecutar previamente el comando 'jpa
gvnix setup'.
2.5.3. Add-on Monitoring
Uso del componente Java Melody como sistema de monitorización para aplicaciones web.
Este Add-on genera una nueva página desde donde podemos ver lo que consume la generación y
ejecución de vistas, consultas, scripts y demás elementos que se generan y componen nuestra
aplicación web.
Para instalarlo, hay que utilizar el comando monitoring setup, el cual instalará todo lo necesario
para el funcionamiento básico de la monitorización de nuestra aplicación. Se encargará de las
dependencias y de modificar los ficheros de configuración necesarios para el funcionamiento de la
monitorizacion de JSP, SQL, consultas, etc.
Para monitorizar a través de las llamadas de Spring, tendremos que configurar que métodos
deseamos monitorizar. Para ello utilizaremos alguno de los siguientes comandos, siempre después
de haber instalado el add-on: monitoring all, monitoring add class, monitoring add method o
monitoring add package. Al ejecutar estos comandos se añadirán anotaciones que nos permitirán
acceder a las llamadas que se ejecuten a los métodos monitorizados y ver sus interacciones.
Una vez todo configurado y con nuestra aplicación en marcha, bastará pulsar en la entrada de
menú que se ha generado para su acceso. En caso de haberla desactivado, bastará con acceder a
la dirección principal de nuestra aplicación, seguida de "/monitoring".
2.5.4. Add-on Web MVC
Add-on de utilidades para la capa Web de tipo Spring MVC.
Este add-on incluye dos funcionalidades:
• Interfaz Web para operaciones de persistencia de entidades en bloque.
• Visualización de vistas usando jQuery como librería de JavaScript.
2.5.5. Add-on Bootstrap
Implementación de Bootstrap 3 en el proyecto gvNIX.
gvHIDRA y gvNIX
Este add-on permite configurar el proyecto gvNIX con la estructura HTML necesaria para
implementar Bootstrap 3. Además, incluye todos los recursos necesarios para modificar la
apariencia de la aplicación por una por defecto basada en Bootstrap 3.
Para instalarlo, hay que utilizar el comando web mvc bootstrap setup, el cual solo estará disponible
después de instalar el add-on JQuery en nuestro proyecto. Este comando detectará de forma
automática, aquellos addons que ya hayan sido instalados y modificará sus componentes para una
correcta visualización utilizando Bootstrap. Además, los addons que se instalen después de
instalar Bootstrap tendrán apariencia Bootstrap por defecto.
Para actualizar los componentes instalados de Bootstrap basta con ejecutar web mvc bootstrap
update, el cual solo estará disponible después de haber instalado Bootstrap.
Para ver con más detalle el comando que proporciona el add-on, consultar la sección de comandos
del add-on Bootstrap.
2.5.6. Add-on Web MVC Datatables
Uso del componente dataTables en las vistas list de los controladores.
Este Add-on reemplaza el widget de lista de las vistas de las entidades para usar el plugin de
jQuery dataTables. Para ello, se usa una adaptación de la librería de tag JSP Dandelion-
DataTables que se integra y adapta a la generación de vistas de Spring Roo.
Las opciones de este add-on no son compatibles con el add-on Web Screen Patterns.
Las principales características de este widget son:
• Ordenación de datos por uno o más campos.
La tabla permite al usuario final ordenar los datos, por una o más columnas, y en el sentido
que el desee. Las columnas disponibles para la ordenación y su sentido son configurables
en la página.
• Filtrados por columnas y búsquedas globales.
Soporta filtrar los datos mostrados por columna, además de hacer búsquedas de texto
sobre los resultados de los filtros. La configuración de que filtros están disponibles para el
usuario se pueden configurar en la página. Además, estos filtros por columna disponen de
un asistente para realizar búsquedas dependiendo del tipo de dato representado en cada
una de ellas.
• Paginación de datos ajustable.
Los datos, filtrados o sin filtrar, se paginan sin necesidad de refrescar la página. El tamaño
de la página puede ser seleccionado por el usuario final.
• Acceso a los datos en la misma página o por petición por AJAX.
Los datos que alimentan la tabla pueden estar integrados en la página o usar peticiones
AJAX para ir solicitándolos a medida que el usuario los requiera.
• Soporta múltiples plugins y es extensible.
Soporta múltiples plugins como ColReorder (permite al usuario reordenar las columnas),
FixedHeader (que mantiene las cabeceras de las columnas visibles cuando se desciende
por páginas largas), etc.
• Registro de Callbacks en distintos eventos.
Soporta registrar funciones JavaScript a ejecutar por el widget cuando: termina la

inicialización, al crear una línea, al pintar el píe de tabla, etc.
• Visualización en modo Registro.
Permite realizar la visualización en modo Registro, es decir, mostrando un registro por

página con sus valores completos.
• Visualización de Detalles.
Se puede añadir la visualización de un o varios detalles (listado de entidades

relacionadas), con varios niveles, al marcar o visualizar (dependiendo del modo de
visualización) un elemento de la tabla.
• Actualización en línea.
Modo que permite actualizar los elementos de la tabla desde la misma línea que los está
visualizando. Es posible modificar multiples registro a la vez.
2.5.7. Add-on Web MVC GEO
Uso del componente Mapa para representar y posicionar entidades que dispongan de campos de
tipo GEO.
Este Add-on permite representar en vistas de tipo Mapa, aquellas entidades que dispongan de
campos de tipo GEO.
Las principales características de este widget son:
gvHIDRA y gvNIX
• Representar entidades en Mapa.
Permite representar aquellas entidades que dispongan de campos de tipo GEO en vistas
de tipo Mapa. Se podrán mostrar/ocultar aquellos campos GEO que se deseen.
• Filtrado de entidades.
Soporta filtrar los registros de una entidad representados en el mapa utilizando el

componente 'Datatable'.
• Selección de entidades.
Permite seleccionar uno o varios datos representados en la vista de Mapa utilizando el

componente 'Datatable'.
• Representar Capas Base en Mapa.
Además de representar entidades en la vista de Mapa, también es posible representar

capas obtenidas desde un servidor de mapas. Es posible representar capas de tipo "tile" y
capas de tipo "WMS".
• Barra de Herramientas.
Este componente dispone de una serie de herramientas que pueden ser añadidas a la vista
de mapa. También se pueden añadir herramientas estándar que el desarrollador puede
personalizar para que realicen las acciones que él desee.
• Personalización de componentes (Markers, Colores, etc.).
Por defecto, la apariencia de las entidades que se representan en el mapa se genera de

forma aleatoria. El desarrollador puede personalizar el icono, el color del icono, el color del
marker o línea, etc. Si la entidad tiene la opción de ser seleccionada desde el componente
'Datatable' podrá configurar también, la apariencia con la que se representará esta entidad
al ser seleccionada. De este mismo modo, se podrá configurar la apariencia de las
herramientas genéricas.
2.5.8. Add-on Campos Lupa
Implementación de campos lupa en el proyecto gvNIX.
Este add-on permite utilizar componentes de tipo lupa en aplicaciones gvNIX. Gracias a estos
componentes, podemos buscar registros de forma sencilla de campos relacionados sin tener que
visualizar todos los datos en un desplegable.
Para instalarlo, hay que utilizar el comando web mvc loupe setup, el cual solo estará disponible
después de instalar el add-on JQuery en nuestro proyecto.
Una vez instalados todos los componentes, es necesario generar una serie de métodos para
realizar las búsquedas y la visualización de los resultados. Para que el controlador disponga de
estos métodos, utilizaremos el comando web mvc loupe set sobre el controlador seleccionado.
Ahora que el Controlador ya dispone de los métodos necesarios, ejecutaremos el comando web
mvc loupe field sobre el field de la entidad a la que pertenece el controlador con los métodos
generados. Una vez ejecutado este comando, transformaremos el campo indicado a un campo de
tipo lupa en la capa web de nuestra aplicación.
Para mantener actualizados los componentes importados mediante el comando de instalación,

podemos ejecutar el comando web mvc loupe update.
Para ver con mas detalle el comando que proporciona el add-on consultar la sección de comandos
del add-on Lupa.
2.5.9. Add-on OCC (Optimistic Concurrency Control)
Add-on de utilidades enfocadas a la persistencia de las entidades.
Este add-on proporciona un sistema que facilita la detección de modificaciones concurrentes en la

persistencia de entidades del modelo de datos.
El sistema consiste en un control de concurrencia optimista basada en un checkSum o suma de

control de los valores de una entidad dada.
Esta utilidad añade a las entidades un sistema de control de concurrencia basado en una
operación de checksum o suma de control sobre todos los campos persistentes que contiene la
entidad.
El control de concurrencia optimista ya es ofrecido por defecto por el núcleo de Spring Roo. Sin
embargo, el sistema que proporciona se basa en la existencia de un campo en cada una de las
tabla de base de datos que se desea controlar. Este campo se suele definir como version
(numérico que identifica la versión del objeto) o lastupdate (fecha de la última actualización). Esto
es un problema para aquellas bases de datos ya existentes y en las que no se puede o no se
quiere alterar su estructura.
Esta funcionalidad nace de la necesidad de controlar la concurrencia sobre modelos de datos

heredados en los que no es posible alterar el modelo relacional de base de datos para añadir los
campos de control en los que se basa el mecanismo de control de concurrencia del núcleo de
Spring Roo que sigue la especificación JPA.
El checksum consiste en una operación matemática de los distintos valores que contiene un
registro (instancia) de una entidad. El cálculo tiene en cuenta todas las propiedades de tipo simple
gvHIDRA y gvNIX
de la entidad, es decir, no se incluye en el cálculo propiedad que represente una relación con otro
u otros objetos. El cálculo se realiza en el momento de la carga del registro de la entidad desde la
base de datos y es almacenado en una propiedad no persistente de la misma entidad.
En el momento de actualizar o eliminar un registro de dicha entidad se carga el elemento que está
persistido en la base de datos y se compara el valor de checksum actual con el que se calculó en
el momento de la carga del elemento a actualizar o eliminar. Si no coincide se lanza una Excepción
(javax.persistence.OptimisticLockException) y la operación no se realizará.
Esta operación supone un coste adicional en las tareas de persistencia, pero no es apreciable en
condiciones del uso cotidiano de la aplicación excepto en procesos de actualizaciones masivas de
registros.
Para mostrar un mensaje amigable al usuario se puede utilizar el Add-on Web Dialog que, en el
conjunto de excepciones gestionadas por defecto se incluye esta. Una vez inicializada la gestión
de excepciones es posible personalizar el mensaje usando el comando web mvc dialog exception
set language.
2.5.10. Add-on Web Dialog
Add-on para la gestión de excepciones no controladas y de mensajes de usuario.
Este add-on permite gestionar las excepciones no controladas en el código de la aplicación y así
mostrar mensajes inteligibles al usuario en una ventana modal (pop-up) y en el idioma actual de la
aplicación sin necesidad de realizar ningún desarrollo en la capa web.
El add-on, al aplicarse sobre un proyecto, por defecto configura ciertas excepciones que serán
visualizadas de forma amigable al usuario en el caso de no ser gestionadas directamente desde la
aplicación. Así mismo, se pueden incluir nuevas excepciones y modificar los textos amigables que
se mostrarán en lugar de la excepción para cada idioma disponible en la aplicación.
Durante su aplicación se instalan algunas cadenas, tanto en ingles como en castellano, para
mostrar mensajes para los errores de conversión de datos numéricos y fechas.
El add-on también permite mostrar mensajes de usuario sin realizar ninguna implementación en la
capa web mediante la invocación de métodos desde el controlador que son los encargados de
mostrar dichos mensajes en la pantalla del usuario.
Los mensajes de excepción y de usuario se muestran en un diálogo o ventana modal. Se permite

además la modificación de las ventanas modales de excepción y de mensaje de usuario para que
puedan ser personalizadas de acuerdo a los requerimientos que sean necesarios.
2.5.11. Add-on Web Report
El add-on añade soporte para la generación de informes con Jasper Reports y genera informes
totalmente funcionales para una entidad que posteriormente pueden ser personalizados. Los
informes son accesibles desde la interfaz web mediante un formulario que se crea para tal efecto.
El add-on añade por un lado el soporte necesario para trabajar con Jasper Reports y por otro es
capaz de generar informes asociados con una entidad cualquiera de la aplicación.
Un informe de Jasper Reports se se define principalmente mediante un archivo de diseño de

informe (jrxml). El diseño de informe al procesarse junto con una fuente de datos, genera un
fichero de salida en un formato determinado incluyendo en él la información existente en la fuente
de datos. La fuente de datos puede provenir de distintos orígenes, aunque en este caso siempre
será una lista de entidades proporcionada directamente desde la aplicación.
El archivo de diseño es un documento XML con un formato determinado que se puede editar de
manera sencilla y gráfica mediante una herramienta como iReport.
2.5.12. Add-on Service
Permite crear servicios locales, servidores de servicios web y clientes de servicios web de forma
automática.
Permite crear de forma automática servicios locales, servidores de servicios web a partir de un
método del código fuente, crear servidores de servicios web basándose en un archivo de
descripción de servicios WSDL y crear clientes de servicios web a partir de un archivo de
descripción de servicios WSDL.
La creación de servicios, del mismo modo que todas las funcionalidades que proporciona el
framework, se realiza mediante anotaciones. Para simplificar esta tarea se puede hacer uso de los
comandos que ofrece. A medida que se van ejecutando comandos del add-on, se van modificando
anotaciones y métodos de la clase Java de forma que acabará conformando el servicio web que se
desea publicar.
2.5.13. Add-on Web MVC i18n
Permite añadir soporte para nuevos idiomas en el proyecto.
Este add-on permite añadir en el proyecto soporte para nuevas lenguas utilizando para ello una
infraestructura común para la inclusión de nuevos idiomas. Al incluir un nuevo idioma, se añaden
en la aplicación de forma automática los textos traducidos a dicho idioma.
gvHIDRA y gvNIX
Los idiomas soportados son: de (Alemán), en (Inglés), es (Español), it (Italiano), nl (Holandés), sv

(Finlandés), ca (Valenciano/Catalán). Este último es añadido por gvNIX utilizando la base del add-
on de idiomas de su núcleo Spring Roo.
2.5.14. Add-on Dynamic Configuration
Este add-on pretende simplificar la gestión de distintos valores de configuración por entorno.
Cuando se utiliza Maven como gestor del ciclo de desarrollo del proyecto existe la posibilidad de
utilizar perfiles para definir los distintos entornos de ejecución que tendrá la aplicación (desarrollo,
pruebas, integración, preproducción, producción,…).
Esta funcionalidad permite configurar el comportamiento de la aplicación de manera distinta según

donde vaya a ser ejecutada. Por ejemplo, la configuración de la conexión con la base de datos de
la aplicación posiblemente será una URL distinta según se esté trabajando en un entorno de
desarrollo o un entorno de producción.
2.5.15. Add-on Web MVC Binding
El add-on permite registrar ciertos editores de propiedades en Spring MVC para uno o todos los
controladores del proyecto.
Los editores son una pieza más de la arquitectura de Spring MVC. Se encargan de controlar el
modo en que las cadenas enviadas por el navegador cliente, por ejemplo desde un formulario, se
convierten en objetos al llegar al servidor.
Para obtener más información sobre los editores de propiedades ver la sección de conversión de
beans de la documentación de Spring.
El comando web mvc binding stringTrimmer permite registrar un editor especialmente útil. Este
editor elimina los espacios en blanco al principio y al final de las cadenas y además permite
transformar las cadenas vacías en valores nulos.
Este editor es especialmente interesante al realizar mantenimientos de valores almacenados en

bases de datos. Por defecto, cuando se deja vacío un valor de un formulario y está relacionado con
una columna de base de datos del tipo cadena, al almacenar se escribe una cadena vacía.
Para cualquier información de más detalle del framework gvNIX puedes consultarlo en la referencia
bibliográfica al final del temario.
(1) Manual de usuario de gvHIDRA versión 4.4.21
(2) http://www.gvnix.org/assets/doc/gvnix-2.0.0.M1-reference-docs/
Tema 31. Software de código abierto. Software
libre. Conceptos base. Aplicaciones y usos.
Normativa sobre propiedad intelectual. Tipos de
licenciamiento de aplicaciones informáticas
Pedro Garrido Águila

Colegiado 0879
La idea del software libre y el código abierto surgió en los años 80 y 90,
consolidándose como un modelo de desarrollo comunitario.
Desde el punto de vista del ingeniero de software, se trata de la diferencia existente

entre disponer de herramientas que te permitan modificar y mejorar el código de
programa o no. Independientemente de que dicho ingeniero pueda realizar esos
cambios y mejoras, nos encontramos con el aspecto jurídico y aquí es donde entra la
regulación de licencias.
Dos de las entidades más relevantes en el desarrollo de licencias de software libre y

código abierto son la Open Source Iniciative y la Free Software Foundation. Estas dos
entidades disponen de licencias de referencia, no obstante, una licencia es un contrato
entre el licenciatario (autor) y el licenciante (adquiriente).
La decisión de adquirir software propietario o software libre debe centrarse en el

estudio de las necesidades de los ingenieros informáticos que vayan a trabajar con
dicho software, así como las garantías de soporte y rapidez de acceso a soluciones.
Por todo esto es sumamente importante que un ingeniero informático responsable de

la administración pública conozca los tipos de licencia existentes tanto a nivel de
código abierto o software libre como de licencias de software propietario.
1. Historia
En los años 70, con la denominada por muchos medios Tercera Revolución Industrial o Revolución
Digital, dando lugar a la Era de la Información, era una práctica natural y común compartir
software, tan natural como era compartir apuntes de clase o recetas de cocina.
Fue en los años 80 cuando proliferó el denominado Software Propietario, el cual, aunque pudieses,
prohibía jurídicamente su modificación o actualización sin el visto bueno de su propietario. Esto
provocó que en 1983, Richard Stallman lanzara el proyecto GNU, motivado anecdóticamente por
un error en la programación del driver de una impresora, cuyo código fuente el propietario se
negaba a revelar, pero que tampoco era capaz de solucionar, al menos en un tiempo razonable. El
principal objetivo del proyecto GNU, consistía en la creación de un sistema operativo completo,
libre de restricciones para el uso, modificación y distribución, ya fuese con mejoras o sin ellas.
Figura 1: La mascota del proyecto GNU, un ñu
En 1985, y motivada por la defensa del Software Libre y en particular del proyecto GNU, Richard
Matthew Stallman, fundó la Free Software Foundation (FSF).
Figura 2: Richard Stallman
Software de código abierto y propiedad intelectual
La primera definición de Software Libre publicada fue en febrero de 1986, basada en dos
principios:
"The word 'free' in our name does not refer to price; it sometimes refer to freedom. First, the freedom to
copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the
freedom to change a program, so that you can control it instead of it controlling you; for this, the source
code must be made available to you".
"La palabra 'libre' en su propio nombre, no se refiere al precio; se refiere a la libertad. Primero, a la
libertad de copiar y redistribuir un programa entre tus vecinos, para que ellos al igual que tu, lo puedan
usar también. Segundo, a la libertad de modificar un programa, y así poder controlarlo en lugar de que
él te controle a tí; para ello, el código fuente debe estar a tu disposición".
Free Software Foundation, 1986
En 1989, se publicó la primera versión de la Licencia Pública General de GNU (GNU General
Public License). El principal problema radicaba en que los propietarios o distribuidores de software,
sólo publicaban los archivos binarios, funcionales y ejecutables, pero no los códigos fuente
perceptibles de ser entendidos y modificados por el ser humano. Por ello la GPLv1 estableció la
obligatoriedad de publicar junto con los archivos binarios el código fuente asociado entendible por
humanos.
En 1991 fue liberada la GPLv2, con una definición de la licencia menos restrictiva. La licencia
Pública General Menor (LGPL) fue renombrada en una actualización menor de la versión 2.1 a
principios de 1999.
En 1991 fue liberado el núcleo Linux por Linus Torvalds, no siendo inicialmente una licencia
totalmente de software libre, pero en febrero de 1992, bajo la versión 0.12, Linus Torvalds la
licenció nuevamente bajo los términos de la Licencia Pública General de GNU.
Figura 3: Linus Torvalds
Esta unión entre Linux y el proyecto GNU, proporcionó a este último la pieza indispensable que
necesitaba, disponer de un sistema operativo casi terminado. La combinación entre ambos resultó
en el primer sistema operativo completo de software libre.
Un aspecto importante a resaltar en la época de los 90 es la vinculación del software libre con
servidores web. El servidor HTTP Apache fue y sigue siendo el software de servidor web más
utilizado. Conocidos como sistemas 'LAMP'; compuesto por un paquete que incluye Linux como
sistema operativo, Apache como proveedor de servicios web, MySQL como sistema de archivo o
base de datos y el lenguaje de programación PHP.
Figura 4: Logo de Apache
A finales de los 90 empezó a acuñarse el término de Código Abierto (Open Source). Promovido por
el movimiento de Netscape Communications Corporation en el sentido de liberación del código de
su suite más popular de internet Netscape Communicator, y debido al poco atractivo para esta
sobre el activismo social de la FSF, en 1998 se fundó la Open Source Initiative (OSI), con el
objetivo de fomentar el nuevo término de Software de Código Abierto, así como sus principios más
centrados en el potencial comercial de compartir código fuente.
2. Software libre
Como hemos comentado, el concepto de software libre apareció vinculado a la figura de Richard
Stallman, la FSF y en el espíritu del autor del software sobre la elección manifiesta para poder ser
copiado, estudiado, modificado y utilizado libremente con cualquier fin, redistribuido con cambios o
mejoras, por otros autores.
El término en su versión inglesa, free software, crea una ambigüedad entre los significados "libre" y
"gratis", por este motivo suele ser considerado el software libre como software gratuito y no como
software que puede ser modificado sin restricciones de licencia. La libertad expresada en el
término free tiene que ver con la libertad de uso y no con la gratuidad.
Por otra parte es importante también distinguir entre software libre y "software de dominio público",
el cual no requiere licencia y es propiedad de todos por igual, con derechos de explotación para
toda la humanidad, dado que su autor así lo ha decidido mediante donación o porque los derechos
de autor de dicho software han expirado.
2.1. Libertades del software libre
De acuerdo a la definición de Richard Stallman, un software es considerado libre cuando cumple

con las cuatro libertades esenciales.
Tabla I: Libertades del software libre
Libertad Descripción
Libertad de usar o ejecutar el programa como lo desees, con cualquier propósito.
0
(Uso).
Libertad de estudiar el código fuente, cómo funciona el programa y modificarlo,
1
adaptándolo a las propias necesidades del programador. (Estudio).
Libertad de ayudar a tu programa, de distribuir copias exactas de él y distribuirlas bien
2 gratuitamente o con la libertad de vender tu desarrollo. Ambas opciones están
permitidas por la comunidad. (Distribución).
Libertad de mejorar el programa y hacer públicas esas mejoras a los demás, hacer
3 copias de tus versiones modificadas y distribuirlas al resto de la comunidad para que
esta se beneficie. (Mejora).
Las libertades 1 y 3 requieren de acceso al código fuente.
Si no se dan estas cuatro libertades en un software, no se considera un software libre, y por tanto
se considera software privativo, en mayor o menor medida, pero privativo.
La ventaja del software libre es que este se acompaña normalmente del código fuente con el que
fue creado y por lo tanto tienes la capacidad de adaptarlo a tus necesidades, con el conocimiento
apropiado, de forma totalmente legal.
Como veremos más adelante, tanto la OSI como la FSF, disponen en sus webs oficiales de
listados con licencias aprobadas por ellos como licencias de software libre.
La definición de software no libre o software privativo, se basa sobretodo en que no garantizan

estas cuatro libertades. Si nos centramos en las leyes de propiedad intelectual, las premisas son la
reserva de derechos sobre modificación, duplicación y redistribución para el propietario del
copyright. En este aspecto, el software libre rescinde específicamente este tipo de derechos
reservados. Unido a estos conceptos, volvemos a diferenciar el concepto de software gratis y
software libre desde el punto de vista que un software gratis puede incluir restricciones que no se
adaptan a la definición de software libre, ya que no cumplen las cuatro libertades.
Es importante diferenciar entre los términos software libre (free software) y software de código
abierto (open source software), el cuál veremos en detalle más adelante. La principal diferencia
radica en que el software libre tiene en cuenta aspectos más éticos o filosóficos, mientras que el
softare de código abierto se basa únicamente en los aspectos técnicos.
2.2. Formatos abiertos
Los formatos libres permiten al software libre mantener sus cuatro libertades, no obstante los
formatos libres pueden ser utilizados por programas libres o programas cerrados, también por
programas gratuitos o programas de pago.
Algunas compañías que no suelen utilizar formatos libres en sus programas, aún así permiten a
sus usuarios instalar software libre en sus sistemas para trabajar con esos formatos.
Algunos ejemplos de formatos libres; HTML, PDF, RTF, TXT, JPEG, PNG, SVG,....
3. Software de código abierto
El 3 de Febrero de 1998 en una reunión en Palo Alto se acuña el término open source y durante la
semana siguiente La idea principal se basaba en poder crear modificaciones de un software,
compatibilizarlo con otros sistemas operativos o arquitecturas de hardware, adaptarlo, compartirlo,
comercializarlo,...
La Open Source Bruce Perens y Eric S. Raymond lanzan opensource.org (http://opensource.org).
Definition define los términos por los cuales se puede usar, modificar o redistribuir el software de
código abierto. Una de las licencias más populares compatibles con la OSD es la GNU General
Public License.
La definición completa de OSD según la OSI:
El código abierto no significa simplemente acceso al código fuente. Los términos de distribución de
software de open-source deben cumplir con los siguientes criterios:
1.- Libre redistribución: La licencia no restringirá a ninguna de las partes de vender o regalar el
software como un componente de una distribución de software que contenga programas de varias
fuentes diferentes. La licencia no exigirá ninguna gratificación u otra tasa por dicha venta.
2.- Código fuente: El programa debe incluir código fuente, y debe permitir la distribución en código
fuente, así como en el formulario compilado. Cuando algún tipo de producto no se distribuye con el
código fuente, debe haber un medio bien publicado para obtener el código fuente por un coste de
reproducción razonable, preferiblemente descargándose a través de Internet sin cargo alguno. El
código fuente debe ser la forma preferida en la que un programador debería modificar el programa. No
se permite un código fuente premeditadamente enrevesado. No se permiten formularios intermedios
tales como la salida de un preprocesador o traductor.
3.- Trabajos derivados: La licencia debe permitir modificaciones y trabajos derivados, y debe permitir
su distribución en los mismos términos que la licencia del software original.
4.- Integridad de código fuente del autor: La licencia puede restringir la distribución del código
fuente modificado sólo si la licencia permite la distribución de ‘archivos de parche’ en el código fuente
con el propósito de de modificar el programa. La licencia debe permitir explícitamente la distribución
de software construido a partir del código fuente modificado. La licencia puede requerir trabajos
derivados para llevar un nombre diferente o número de versión del software original.
5.- No discriminación contra personas o grupos: La licencia no debe discriminar a ninguna persona
o grupo de personas.
6.- No discriminación por los campos de trabajo: La licencia no debe restringir a nadie el uso del
programa en un campo de trabajo específico. Por ejemplo, puede no restringir el uso del programa en
un negocio, o de ser utilizado para la investigación genética.
7.- Distribución de la licencia: Los derechos vinculados al programa deben aplicarse a todos
aquellos a quienes se redistribuye el programa sin necesidad de que estos ejecuten una licencia
adicional.
8.- La licencia no debe ser específica para un producto: Los derechos vinculados al programa no
deben depender de que el programa sea parte de una distribución de software en particular. Si el
programa se extrae de esa distribución y se utiliza o distribuye dentro de los términos de la licencia del
programa, todas las partes a las que se redistribuye el programa deben tener los mismos derechos
que los otorgados en conjunto con la distribución de software original.
9.- La licencia no debe restringir otro software: La licencia no debe suponer restricciones sobre
otro software que se distribuye junto con el software con licencia. Por ejemplo, la licencia no debe
exigir en que todos los demás programas distribuidos en el mismo medio deben ser de código abierto.
10.- La licencia Debe Ser Tecnología-Neutral: Ninguna disposición de la licencia puede basarse en
una tecnología individual o en un estilo de interfaz.
Open Source Iniciative, (Last Update 2007-03-22)
Entre los años 1998 y 2000, el crecimiento y popularidad de la filosofía de código abierto, la
consolidación de GNU/Linux y la aparición de nuevas empresas con ideales de software de código
abierto, llevó a que empresas como Sun Microsystems o IBM a ofertar productos como StarOffice o
OpenAFS respectivamente.
El 8 de Junio de 2015 Apple anuncia Swift 2 bajo licencia código abierto.
4. La protección del software
4.1. Introducción
El avance informático producido en el último tercio del siglo XX supuso que el software adquiriese
una relevancia que no se preveía, habida cuenta que el software inicialmente se comercializaba
como un elemento conexo del hardware sin que fuese objeto de una explotación económica
independiente. Desde el momento en que dichos programas tienen sustantividad propia, se pone
de manifiesto la importancia de regular su comercialización autónoma, a través de la vinculación a
una institución que permitiese el reconocimiento jurídico de dicha creación, el aprovechamiento
lucrativo de la obra y el impedimento de la explotación por quien no estuviese autorizado para ello.
Así, tanto en nuestra legislación nacional como en los textos internacionales de los que España
forma parte, se ha optado por considerar este software como una obra de protección a través del
derecho de autor, siempre que cumpla los requisitos que para ello se exigen.
4.2. Especialidad del objeto protegido
La protección otorgada al software, se ha considerado una propiedad especial en cuanto a su

objeto, de la que se derivan una serie de derechos o facultades, tanto desde el punto de vista
moral como desde el punto de vista patrimonial. El TRLPI (Texto Refundido de la Ley de Propiedad
Intelectual) conceptúa el término de software, en su artículo 96, como “toda secuencia de
instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema
informático para realizar una función o una tarea para obtener un resultado determinado,
cualquiera que fuera su forma de expresión y fijación”. La amplitud de dicho concepto viene
determinada fundamentalmente por el propósito de evitar que se plasmase una definición que
llegase a quedar obsoleta ante los presumibles y continuos avances tecnológicos. Para concretar,
en parte, la genérica definición, recoge igualmente la Ley que la protección se extiende a la
documentación preparatoria, a la documentación técnica y los manuales de uso, y a cualesquiera
versiones sucesivas del programa así como a los programas derivados. Por el contario, no gozarán
de dicha protección, los virus y otros programas que tengan por finalidad ocasionar efectos nocivos
a un sistema informático, ni las ideas y principios en los que se base cualquiera de los elementos
de software, incluido el que sirve de fundamento a sus interfaces.
4.3. Requisitos para su protección
La protección del derecho de autor, sólo tendrá lugar si el software resulta original (creación
intelectual propia de su autor) expresada por cualquier medio o soporte, tangible o intangible,
conocido o por conocer. Respecto a la originalidad de la obra, la Directiva Europea transpuesta,
descarta expresamente que se utilicen criterios cualitativos o relativos al mero valor estético del
software. Por tanto, el software que cumpla dichos requisitos, gozará del amparo y garantías del
derecho de autor, sea cual fuera la funcionalidad del mismo (de aplicación y periférica, o de
aplicación), y quedando bajo dicha protección tanto el código fuente como el objeto, ya que
estaríamos siempre ante el mismo software, pero con un lenguaje o código distinto.
4.4. Derechos morales de los creadores de software
Como los creadores de todas las obras protegidas que se regulan en la Ley de Propiedad
Intelectual, los autores de software, ostentan derechos de explotación y derechos morales sobre
sus creaciones. Si bien el legislador ha querido atender a las características de la obra creada,
para establecer una reglamentación especial dentro del derecho respecto al software, en los
preceptos que la componen, no se establece regulación alguna de los derechos morales, por lo
que, se aplicaran los genéricos recogidos en los artículo 14 LPI, si bien, para su eficacia y el
alcance de su contenido, habrá que estarse a las características propias de dicha creación.
4.5. Derechos de explotación de software
A diferencia de lo aducido respecto de los derechos morales del autor, la LPI sí recoge un marco
regulatorio propio de los derechos patrimoniales o económicos con respecto al software,
precisamente, por la especialidad del objeto de protección. Estos derechos son los siguientes:
a) El derecho de reproducción. A través de la protección de esta facultad, se reconoce al titular

el derecho a realizar o autorizar la reproducción total o parcial, incluso para uso personal, de
software, por cualquier medio y bajo cualquier forma ya fuere permanente o transitoria. Dado el
carácter fácilmente reproducible de este tipo de obras, el uso en cualquier forma de software,
debe contar con la autorización del titular.
b) El derecho de transformación. A través de la protección de esta facultad, se reconoce al

titular el derecho a realizar o autorizar la traducción, adaptación, arreglo o cualquier otra
transformación de un software y la reproducción de los resultados de tales actos, sin perjuicio
de los derechos de quien transforme el software. Por tanto, corresponderá al titular, el derecho
de autorizar las versiones sucesivas del software o las transformaciones que resultasen
precisas para adaptar el software original a las necesidades del usuario legítimo del mismo. No
obstante, se admitirá la transformación sin autorización por parte de su titular cuando adquirido
lícitamente programa, éste no fuese compatible con el sistema operativo que utiliza el usuario y
se hiciesen sobre el programa las transformaciones y adaptaciones necesarias para garantizar
la interoperabilidad.
c) El derecho de distribución. A través de la protección de esta facultad, se reconoce al titular el

derecho a realizar o autorizar cualquier forma de distribución pública del software, es decir, su
comercialización o puesta a disposición del público a través de soportes tangibles, incluyendo
el alquiler del programa original o de sus copias.
d) El derecho de comunicación pública. El TRLPI no hace mención expresa a esta facultad de

explotación respecto al software. Ello trae causa en que la amplitud de los supuestos previstos
para la reproducción y la consiguiente exigencia de autorización, supone que no pueda
concebirse la comunicación pública de software sin que se produzca necesariamente su
reproducción. No obstante, se viene considerando comunicación pública, la puesta a
disposición del público, a través de Internet, o de redes intranet, facilitándose las descargas.
4.6. Límites legales a los derechos de explotación
A pesar de las amplias facultades cuasi-monopolísticas que reconoce la Ley a los autores de
software, marca también una serie de supuestos que actúan como límites legales a los derechos
de explotación, y que no necesitarían autorización, que son:
a) La reproducción o transformación, incluida la corrección de errores, que resultasen

necesarios para su utilización con arreglo a su finalidad por parte del usuario legítimo.
b) La realización de copia de seguridad o salvaguarda del software.
c) La llamada ingeniería inversa: Examen funcional de las ideas y fundamentos del software
para poder comprobar los aspectos precisos a fin de llevar a cabo aquellas tareas.
d) La realización de versiones sucesivas: No podrá oponerse el autor, a que el cesionario

realice o autorice la realización de versiones sucesivas de su software ni de software derivado
del mismo, salvo pacto en contra.
e) La descompilación e interoperabilidad: El usuario legítimo podrá realizar en él los actos de

reproducción y transformación que sean indispensables para obtener la interoperabilidad del
software en relación con determinadas situaciones, límites y objetivos. Los supuestos de
descompilación no podrán ser interpretados de manera que su aplicación perjudique de forma
injustificada los legítimos intereses del titular de los derechos.
f) Las limitaciones genéricas de los artículos 31 a 40 deberán valorarse, en cada caso,

porque algunos supuestos, son de muy difícil aplicación.
g) El límite temporal: El plazo de protección, es el de la vida del autor más 70 años después de
su muerte o declaración de fallecimiento. En caso de obra en colaboración, el cómputo de los
70 años, se iniciará con el fallecimiento del último de los autores. Si la titularidad pertenece a
una persona jurídica, la duración será de 70 años desde el 1 de enero del año siguiente al de
su divulgación.
4.7. Especificidad de ciertos tipos de autoría y repercusión en la atribución

de derechos
La ley de propiedad intelectual parte como un principio general, de que el autor es siempre una
persona física, pero a su vez, favorece la atribución de la condición de autor de software a las
personas jurídicas. Por tanto, será considerado autor del software la persona o grupo de personas
naturales que lo hayan creado; o, en su caso, la persona jurídica que sea contemplada como titular
de los derechos de autor en los supuestos expresamente previstos por el TRLPI. No olvidando
cada uno de los tipos de obras en función de su autoría, merecen ser traídos a colación dos
supuestos especiales de regulación que, adquieren por ello relevancia y que serían:
a) Autoría en el marco de un arrendamiento de obra: Se trataría del encargo de la creación de

un software con su posterior implantación, en determinadas condiciones de operatividad para
los cometidos, áreas o tareas que interesan al cliente. Se mantienen en todo caso a favor del
creador los derechos morales, dada su indisponibilidad, limitándose por tanto, la propiedad del
comitente respecto al soporte (tangible o intangible) en que se hubiese exteriorizado dicha
creación intelectual y sus facultades de explotación.
b) Autoría en el marco una relación laboral: Cuando un trabajador asalariado cree un software
en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su
empresario, la titularidad de los derechos de explotación correspondientes al software, así
creado, tanto el código fuente como el código abierto, corresponderán exclusivamente al
empresario, salvo pacto en contrario. Además, se genera una presunción de que autoriza al
empresario la realización de versiones sucesivas del mismo, salvo que esta facultad hubiera
sido descartada con pacto en contra.
4.8. Interacción con la protección mediante patentes
La ley de patentes 11/1986 establece que no puede protegerse el software como tal al no tratarse
de una invención de aplicación industrial. Están excluidos de la protección del Derecho de patentes
porque se considera que no son invenciones en el sentido que exige la Ley, ya que una invención
debe constituir la solución a un problema técnico. No obstante, cuando la ejecución del software
produce efectos técnicos, puede formar parte de una invención patentable, de modo que el
software sea un elemento integrado dentro del objeto sobre el que recae la patente, siempre y
cuando, se cumplan los requisitos de patentabilidad de las invenciones, que son:
• Que implique una actividad inventiva
• Que sea una invención nueva
• Que sea susceptible de aplicación industrial.
En la protección de invenciones implementadas por ordenador a través de patente, por su parte,

resulta clave el código objeto.
4.9. Protección del diseño de interfaces gráficas e iconos a través de

diseños industriales
Entre los diferentes productos creativos generados por la industria TIC, existen una serie de
creaciones caracterizadas especialmente por su configuración estética. Se trata de productos cuya
forma no está diseñada con la finalidad de mejorar la utilidad del producto, sino con la de hacerlo
más atractivo para el mercado. El diseño de las interfaces gráficas o los iconos que se presentan
en los ordenadores, teléfonos móviles o tabletas, pueden protegerse como diseños industriales a
través de su registro en la Oficina que corresponda, siendo la competente a nivel nacional, la
OEPM. Para que la Oficina proceda a registrar el diseño, es necesario que sea nuevo y que posea
carácter singular (que la impresión general de un usuario informado difiera de la producida por
cualquier otro diseño).
4.10. Conclusión
Los creadores dentro de la llamada “Industria TIC”, han de conocer los derechos que les asisten,
tanto para su propia protección como para la elaboración jurídicamente segura de software. Para
ello, se aconseja la adopción de una serie de medidas elementales, dirigidas a evitar infracciones
de derechos de terceros, y problemáticas propias, que son:
a) Utilizar herramientas informáticas licenciadas para el uso lucrativo, en caso de que sea éste el
uso que pretenda darse a la creación.
b) En caso de que se quieran incluir en el programa elementos preexistentes elaborados por

terceros, obtener éstos las correspondientes licencias.
c) Organizar la atribución de derechos de Propiedad Intelectual entre todos los autores que
intervengan en la creación del software.
La observancia de dichas precauciones mínimas, favorecerán la explotación pacífica de la obra

creada.
4.11. Artículos del Real Decreto Legislativo 1/1996, de 12 de abril, por el que
se aprueba el texto refundido de la Ley de Propiedad Intelectual.
4.11.1. Artículos 95 Régimen jurídico
El derecho de autor sobre el software se regirá por los preceptos del presente Título y, en lo que
no esté específicamente previsto en el mismo, por las disposiciones que resulten aplicables de la
presente Ley.
4.11.2. Artículos 96 Objeto de la protección
1. A los efectos de la presente Ley se entenderá por software toda secuencia de instrucciones o
indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático
para realizar una función o una tarea o para obtener un resultado determinado, cualquiera que
fuere su forma expresión y fijación.
A los mismos efectos, la expresión software comprenderá también su documentación

preparatoria. La documentación técnica y los manuales de uso de software gozarán de la
misma protección que este Título dispensa al software.
2. El software será protegido únicamente si fuese original, en el sentido de ser una creación
intelectual propia de su autor.
3. La protección prevista en la presente Ley se aplicará a cualquier forma de expresión de

software. Asimismo, esta protección se extiende a cualesquiera versiones sucesivas del
software así como al software derivado, salvo aquellas creadas con el fin de ocasionar efectos
nocivos a un sistema informático.
Cuando el software forme parte de una patente o un modelo de utilidad gozarán, sin perjuicio
de lo dispuesto en la presente Ley, de la protección que pudiera corresponderles por aplicación
del régimen jurídico de la propiedad industrial.
4. No estarán protegidos mediante los derechos de autor con arreglo a la presente Ley, las ideas
y principios en los que se basan cualquiera de los elementos del software incluido el que sirve
de fundamento a sus interfaces.
4.11.3. Artículos 97 Titularidad de los derechos
1. Será considerado autor del software la persona o grupo de personas naturales que lo hayan
creado, o la persona jurídica que sea contemplada como titular de los derechos de autor en los
casos expresamente previstos por esta Ley.
2. Cuando se trate de una obra colectiva tendrá la consideración de autor, salvo pacto en
contrario, la persona natural o jurídica que la edite y divulgue bajo su nombre.
3. Los derechos de autor sobre el software que sea resultado unitario de la colaboración entre
varios autores serán propiedad común y corresponderán a todos éstos en la proporción que
determinen.
4. Cuando un trabajador asalariado cree un software, en el ejercicio de las funciones que le han
sido confiadas o siguiendo las instrucciones de su empresario, la titularidad de los derechos de
explotación correspondientes al software así creado, tanto el programa fuente como el
programa objeto, corresponderán, exclusivamente, al empresario, salvo pacto en contrario.
5. La protección se concederá a todas las personas naturales y jurídicas que cumplan los
requisitos establecidos en esta Ley para la protección de los derechos de autor.
4.11.4. Artículos 98 duración de la protección
1. Cuando el autor sea una persona natural, la duración de los derechos de explotación del
software será, según los distintos supuestos que pueden plantearse, la prevista en el capítulo I
del Título II de este Libro.
2. Cuando el autor sea una persona jurídica la duración de los derechos a que se refiere el
párrafo anterior será de setenta años, computados desde el 1 de enero del año siguiente al de
la divulgación lícita del software o al de su creación si no se hubiere divulgado.
4.11.5. Artículo 99 Contenido de los derechos de explotación
Sin perjuicio de lo dispuesto en el artículo 100 de esta Ley de los derechos exclusivos de la
explotación de software por parte de quien sea su titular con arreglo al artículo 97, incluirán el
derecho de realizar o de autorizar:
a) La reproducción total o parcial, incluso para uso personal, de software, por cualquier medio y
bajo cualquier forma, ya fuere permanente o transitoria. Cuando la carga, presentación,
ejecución, transmisión o almacenamiento del software necesiten tal reproducción deberá
disponerse de autorización para ello, que otorgará el titular del derecho.
b) La traducción, adaptación, arreglo o cualquier transformación del software y la reproducción de

los resultados de tales actos, sin perjuicio de los derechos de la persona que transforme el
software.
c) Cualquier forma de distribución pública incluido el alquiler del software original o de sus copias.
A tales efectos, cuando se produzca cesión del derecho de uso del software se entenderá salvo
prueba en contrario, que dicha cesión tiene carácter no exclusivo e intransferible, presumiéndose,
asimismo, que lo es para satisfacer únicamente las necesidades del usuario. La primera venta en
la Unión Europea de una copia de software por el titular de los derechos o con su consentimiento,
agotará el derecho de distribución de dicha copia, salvo el derecho de controlar el subsiguiente
alquiler del software o de una copia del mismo.
4.11.6. Artículo 100 Límites a los derechos de explotación
1. No necesitarán autorización del titular, salvo disposición contractual en contrario, la

reproducción o transformación del software No necesitarán autorización del titular, salvo
disposición contractual en contrario, la reproducción o transformación del software incluida la
corrección de errores, cuando dichos actos sean necesarios para la utilización del mismo por
parte del usuario legítimo, con arreglo a su finalidad propuesta.
2. La realización de una copia de seguridad por parte de quien tiene derecho a utilizar el software
no podrá impedirse por contrato en cuanto resulte necesaria para dicha utilización.
3. El usuario legítimo de la copia del software estará facultado para observar, estudiar o verificar
su funcionamiento, sin autorización previa al titular, con el fin de determinar las ideas y
principios implícitos en cualquier elemento del software, siempre que lo haga durante
cualquiera de las operaciones de carga, visualización, ejecución, transmisión o

almacenamiento del software derivado del mismo.
4. El autor, salvo pacto en contrario, no podrá oponerse a que el cesionario titular de derechos de
explotación realice o autorice la realización de versiones sucesivas del software ni de software
derivado del mismo.
5. No será necesaria la autorización del titular del derecho cuando la reproducción del código y la
traducción de su forma ene l sentido de los párrafos a) y b) del artículo 99 de la presente Ley,
sea indispensable para obtener la información necesaria para la interoperabilidad del software
creado de forma independiente con otros programas, siempre que se cumplan los siguientes
requisitos:
a) Que tales actos sean realizados por el usuario legítimo o por cualquier otra persona
facultada para utilizar una copia del software, o, en su nombre, por parte de una persona
debidamente autorizada.
b) Que la información necesaria para conseguir la interoperabilidad no haya sido puesta

previamente y de manera fácil y rápida, a disposición de las personas a que se refiere el
párrafo anterior.
c) Que dichos actos se limiten a aquellas partes del software original que resulten necesarias
para conseguir la interoperabilidad.
6. La excepción contemplada en el apartado 5 de este artículo será aplicable siempre que la

información así obtenida:
a) Se utilice únicamente para conseguir la interoperabilidad del software creado de forma

independiente.
b) Sólo se comunique a terceros cuando sea necesario para la interoperabilidad del software
creado de forma independiente.
c) No se utilice para el desarrollo, producción o comercialización del software sustancialmente

similar en su expresión, o para cualquier otro acto que infrinja los derechos del autor.
7. Las disposiciones contenidas en los apartados 5 y 6 del presente artículo no podrán

interpretarse de manera que permitan que su aplicación perjudique de forma injustificada los
legítimos intereses del titular de los derechoso sea contraria a una explotación normal del
software informático.
4.11.7. Artículo 101 Protección registral
Los derechos sobre el software, así como sus sucesivas versiones y el software derivado, podrán
ser objeto de inscripción en el Registro de la Propiedad Intelectual.
Reglamentariamente se determinarán aquellos elementos del software registrado que serán

susceptibles de consulta típica.
4.11.8. Artículo 102 Infracción de los derechos
A efectos del presente título y sin perjuicio de lo establecido en el artículo 100 tendrán la
consideración de infractores de los derechos de autor quienes sin autorización del titular de los
mismos, realicen los actos previstos en el artículo 99 y en particular:
a) Quienes pongan en circulación una o más copias del software conociendo o pudiendo presumir
su naturaleza ilegítima.
b) Quienes tengan con fines comerciales una o más copias del software, conociendo o pudiendo
presumir su naturaleza ilegítima.
c) Quienes pongan en circulación o tengan con fines comerciales cualquier instrumento cuyo
único uso sea facilitar la supresión o neutralización no autorizadas de cualquier dispositivo
técnico utilizado para proteger el software.
4.11.9. Artículo 103 Medidas de protección
El titular de los derechos reconocidos en el presente Título podrá instar las acciones y
procedimientos que, con carácter general, se disponen en el Título I, Libro III de la presente Ley y
las medidas cautelares procedentes, conforme a lo dispuesto en la Ley de Enjuiciamiento Civil.
4.11.10. Artículo 104 Salvaguardia de aplicación de otras disposiciones legales
Lo dispuesto en el presente Título se entenderá sin perjuicio de cualesquiera optras disposiciones

legales tales como las relativas a los derechos de patente, marcas, competencia desleal, secretos
comerciales, protección de productos semiconductores o derecho de obligaciones.
(1) Ley 16/1993, de Incorporación al derecho Español la Directiva 91/250/CEE, de 14 de mayo de

1991, sobre la protección jurídica de programas de ordenador. Boletín Oficial del estado.
(3) Real Decreto Legislativo 1/1996, de 12 de Abril, por el que se aprueba el texto refundido de la
Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones
legales vigentes sobre la materia.
(4) https://opensource.org/. Página oficial de la Open Source Iniciative.
(5) http://www.fsf.org/. Página oficial de la Free Software Fondation.
(6) https://www.gnu.org/. Página oficial del proyecto GNU.
(7) Valdecantos Flores, Maitane. Artículo: "Talento TIC: La protección del Programa de
Ordenador". Eurotax Abogados
Tema 32. Sistemas CRM (Customer Relationship
Management) y ERP (Enterprise Resource
Planning). Beneficios y usos
Antonio Crespo Roures

Colegiado 940
En este tema se va a definir qué son los sistemas CRM y ERP que se están
implantando cada vez más en el mundo empresarial, gracias sobre todo, al gran
avance de las nuevas tecnologías. Se mostrará su funcionalidad, las partes en que
están divididos, los tipos que existen, cómo implantarlos, y se citarán ejemplos de
aplicaciones tanto de CRM como de ERP, además de las ventajas y beneficios que
obtiene una empresa al utilizarlos.
1. Sistemas CRM (Customer Relationship Management)
La sigla CRM viene del inglés customer relationship management. Este término no sólo se refiere
al software que utilizamos para la gestión y administración de las relaciones de una empresa con
sus clientes. Se puede definir como una serie de estrategias, prácticas y tecnologías enfocadas a
gestionar, administrar y ver las futuras necesidades de los clientes anticipándose a ellas.
En una pequeña empresa se conoce a los clientes por su nombre, se sabe los productos que suele
adquirir o qué servicios utiliza. Se tiene un trato más directo consiguiendo fidelizar al cliente y que
vuelva a comprar los productos ofrecidos, pues al estar más en contacto se puede conocer su
satisfacción. En cambio, esta relación tan estrecha no se puede mantener cuando una empresa
crece. Llegando un momento que ya no se pueden conocer a todos los clientes ni sus
necesidades, perdiendo la ventaja competitiva que tenía la pequeña empresa. Este fue uno de los
motivos de la aparición del CRM, surgió una carencia que podía ser subsanada gracias al avance
de las tecnologías de la información. Hoy en día, se ve reforzado con el uso de las redes sociales
donde se puede recoger gran cantidad de información sobre las opiniones de clientes, que
posteriormente puede ser explotada por sistemas informáticos.
El objetivo del sistema CRM es mejorar las relaciones y servicios de la empresa con sus clientes.
Se podría decir que el CRM vela por la satisfacción del cliente en todo momento, antes, durante y
después de realizar el servicio o venta. Resumiendo nos permitirá incrementar y fidelizar clientes.
Implantar un sistema CRM en una empresa suele suponer un fuerte gasto económico y temporal,
pero una vez está funcionando correctamente, se tendrá una ventaja competitiva frente a la
competencia permitiendo el crecimiento de la empresa.
Los sistemas CRM ofrecen a las empresas la posibilidad de personalizar sus relaciones con cada
uno de sus clientes. Con la creación de una base de datos de clientes, se consigue que cada
empleado conozca las necesidades de cada uno de ellos, independientemente de si ha trabajado
con ellos o no. Es una clara forma de mejorar los servicios de la empresa hacia los clientes
mejorando la relación cliente-empresa.
1.1. Módulos en sistemas CRM
El software CRM guarda toda la información referente a los clientes en bases de datos. La
estructura del CRM está divida en varios módulos en función del tipo de información que almacena.
Cada proveedor de software implementa distintos módulos en función de la finalidad de su

aplicación. Posteriormente éstos también serán adaptados a las necesidades de la empresa donde
se vaya a utilizar. Los módulos más comunes son los siguientes: clientes, ventas y marketing.
Sistemas CRM y ER. Beneficios y usos.
1.1.1. Módulo clientes
• Proporciona información del perfil de cliente.
• Identifica las fases de la negociación.
• Gestiona histórico de la relación comercial con el cliente.
• Soporte al cliente.
1.1.2. Módulo ventas
Herramienta de soporte informático dirigida al departamento comercial para conocer a tiempo real
el estado de la negociación con cliente.
• Gestión y automatización de ventas.
• Gestión de cierres de las negociaciones.
• Fidelización del cliente.
1.1.3. Módulo marketing
• Segmentación de clientes.
• Gestión de campañas.
• Planificación de ventas.
• Análisis de marketing.
1.2. Tipos de CRM
A continuación se va a ver los tres tipos de CRM que existen. Hay que tener en cuenta que están
muy relacionados entre sí, que interactúan entre ellos y algunos componentes incluso están
solapados en los distintos tipos.
1.2.1. CRM Colaborativo
El CRM colaborativo es el que más ha cambiado recientemente debido al avance de las nuevas
tecnologías y las nuevas formas de comunicarse con el cliente. Consiste en la comunicación
empresa-cliente: son los diversos medios que puede utilizar el cliente para obtener información,
por ejemplo vía telefónica, web, etc. Es común hoy en día en muchas empresas que los clientes
accedan a través del portal web de la empresa para hacer pedidos, conocer el estado un pedido ya
realizado, realizar consultas, etc.
1.2.2. CRM Operacional
La mayor parte del CRM operacional se encuentra en el back office de la empresa. Incluye las
siguientes funcionalidades:
• Servicio y soporte a clientes: información sobre productos, reclamaciones y devoluciones.
• Ventas: incluye todo el proceso de venta de un producto o servicio.
• Marketing: estudia y analiza tendencias de mercado y competencia.
1.2.3. CRM Analítico
El CRM analítico se encarga de analizar los datos almacenados en una base de datos, obtenidos a
partir de los otros componentes del CRM. Se generan informes a partir de datos de clientes. Se
aplican técnicas de business intelligence y minería de datos para obtener nueva información del
comportamiento de los clientes.
1.3. Implantación de un CRM
La implantación de un sistema CRM no hace referencia solamente a la instalación de un software,

sino que se modificará la forma de trabajar, los procesos actuales y la orientación de los
empleados se enfocará a conseguir la satisfacción del cliente.
El proceso de implantación de un CRM es muy costoso económica y temporalmente. Estará

dividido en una serie de fases que se llevarán a cabo de forma cronológica. Las fases en las que
se divide la implantación de un CRM son las siguientes:
• Estudio de la situación actual y necesidades de mejoras.
• Definición del CRM conforme al análisis de requisitos y necesidades.
• Diseño y programación de la herramienta.
• Implantación.
• Formación.
• Puesta en marcha.
• Transición.
• Mantenimiento y seguimiento.
Es muy importante en todo el proceso de implantación que el personal de la empresa donde se

implanta el CRM esté involucrado, motivado y tenga una mentalidad positiva frente al cambio.
1.4. Ejemplos de software CRM
Se puede encontrar una gran variedad de software CRM de múltiples proveedores. A continuación
se van a citar algunos de los más utilizados junto con las empresas que lo utilizan:
• Oracle PeopleSoft: Corona S.A., Cosméticos Avon S.A., Wal-Mart y Toyota. Software
preparado para trabajar con empresas de tamaño mediano y grande. Es muy adaptable,
puede ser utilizado en cualquier tipo de industria en función de sus necesidades. Sus
principales capacidades son gestión de ventas, marketing, soporte y servicio al cliente.
• mySAP CRM: Philips, Heineken, Schenider Electric, Eon, Allianz, Soudal y BMW Group. Es
una de las aplicaciones más utilizadas a nivel mundial. Ofrece un conjunto de herramientas
que ofrecen la solución adecuada para centrar los objetivos en los clientes. Contiene las
siguientes funcionalidades:
Gestión de contabilidad y contactos.
Gestión de ventas.
Gestión de productos y precios.
Previsión de ventas.
Gestión de correos electrónicos a clientes y campañas de marketing.
Informes y cuadros de mandos.
• Microsoft Dynamics CRM: Hitachi, Real Madrid F.C., Volvo y Barclays Bank. Es la solución
de Microsoft que permite a las empresas realizar la gestión de las relaciones con el cliente.
Se puede utilizar desde cualquier lugar, mejora el proceso de venta y ayuda a realizar
mejores campañas de marketing. Está compuesto por 3 módulos principales: ventas,
marketing y servicio al cliente.
Ventas: Gestión el proceso de venta.
Marketing: Gestión de campañas y comunicaciones vinculado con el módulo de ventas

para ver los resultados de las promociones realizadas.
Servicio al cliente: Repositorio de toda la información de clientes, incidencias,

consultas e históricos de servicios.
• CRM Sage: Sage Group, Seelogic Ltd y Catel. Software para pequeñas y medianas
empresas de hasta 500 empleados, soporta hasta 200 empleados concurrentes. Dirigido a
cualquier sector de actividad. Tiene ediciones especiales para los sectores de fabricación,
distribución y servicios. Funcionalidades:
Permite la gestión de agenda y contactos.
Organización del ciclo comercial y ventas.
Planificación campañas marketing.
Supervisión del departamento de atención al cliente.
Las aplicaciones citadas anteriormente son software propietario, pero también podemos encontrar
versiones de software libre CRM o programas que constan de versión básica gratuita y otra más
completa de pago. En función de las necesidades de la empresa se seleccionará un programa u
otro. A continuación se citarán algunos ejemplos de software CRM no propietario junto con el
nombre de empresas que los utilizan:
• Sugar CRM: Coca-Cola, Man, Reebok y Loomis. Aplicación para empresas de distinto
tamaño. Dispone varias ediciones una de ellas es libre y el resto utiliza componentes no
libres. Es utilizada en las áreas de gestión comercial, marketing y atención al cliente.
Mejora la gestión con clientes en tres ejes principales de la cadena de valor:
Automatización de las actividades del equipo comercial.
Control de las actividades de marketing, y análisis relacional con los resultados de la

actividad comercial.
Atención y servicio al cliente. Gestión de incidencias y reclamaciones.
• Suma CRM: RE/MAX, Quality Secure, Webtools y Global Alumni. Software destinado a
pequeñas empresas con las funcionalidades necesarias para que resulte fácil de utilizar y
útil a la vez. A continuación se van a citar sus principales características:
Centralización de toda la información de contactos.
Permite crear tareas y especificar su tipo: reuniones, llamadas, presupuestos, etc.
Se puede realizar seguimiento de ventas.
Permite importar y exportar documentos.
Comunicación con contactos a través del correo electrónico.
Posee un módulo denominado “casos” para gestionar proyectos internos.
• vTiger: Contus, Elobe, MowGreen y GB Advisors. Se crea a partir de Sugar CRM para
obtener una herramienta similar pero de código abierto. Tiene una Licencia Pública de
Mozilla. A continuación se va a citar sus principales características:
Es una aplicación web basada en estándares abiertos como: MySQL, PHP, Bootstrap,
Html, Javascript.
Cuenta con una gran comunidad de desarrolladores que permiten adaptar el software a
nuestras necesidades.
No sólo cuenta con módulos propios de un CRM sino que además añade módulos de
pedidos, facturas, pagos, productos propios de soluciones ERP.
Se integra con aplicaciones como Outlook o Thunderbird, Wordpress, Prestashop y

Mailchimp.
Permite automatización de los envíos de correos y la gestión de campañas y

comunicaciones comerciales.
Para ampliar información sobre cada uno de los CRM tanto propietarios como gratuitos se puede
acceder a su correspondiente página web.
2. Sistemas ERP (Enterprise resource planning)
La sigla ERP viene de las palabras en inglés Enterprise Resource Planning que se podría traducir
como planificación de los recursos de la empresa. Este término engloba una serie de procesos de
negocio como son la contabilidad, almacén, producción, distribución, logística, etc. Los sistemas
ERP facilitan el flujo de información desde distintos módulos a gerencia con el fin de ayudar a la
toma de decisiones.
Como se ha comentado un ERP está formado por distintos módulos independientes. No tienen por
qué estar todos implantados en la empresa, pero cuantos más estén más información será capaz
de recoger y explotar. Cada departamento suele tener su módulo optimizado para la recogida y
gestión de su propia información que podrá ser transmitida a otros módulos cuando sea de su
interés. Esta información suele ser modificada en tiempo real lo que permite una toma de
decisiones más rápida y eficiente.
El software ERP normalmente se suele implantar en las empresas por profesionales

especializados en ese determinado ERP adaptando el programa a las necesidades de la empresa.
Una vez implantado necesitará ser modificado en función de las futuras necesidades que vayan
surgiendo.
Algunos sistemas ERP incluyen un módulo CRM que si la empresa lo implanta se podría realizar la
gestión tanto del frontend (CRM) como del backend (ERP).
Las herramientas ERP mejoran la eficiencia de las empresas integrando procesos de

negocio en un único sistema permitiendo gestionar los objetivos planificados.
2.1. Módulos de un ERP
En función del proveedor de software ERP se dispondrá de más o menos módulos implementados.
En esta sección se comentarán los módulos más comunes que se suelen encontrar en un ERP,
que pueden coincidir con las unidades departamentales de la empresa. Para decantarse por un
ERP u otro la empresa también deberá de valorar cuál se adapta mejor a sus necesidades, y que
módulos necesita. Los módulos que suelen aparecer en todos los ERP son los siguientes:
• Producción.
• Gestión de stocks.
• Finanzas: actividad financiera y contable empresarial.
• Recursos humanos.
• Marketing y ventas.
• CRM muchos proveedores de software incluyen un módulo de CRM como un módulo más
del ERP.
• Gestión de la cadena de suministro.
• Informes.
2.2. Tipos de ERP
Se va a clasificar los ERP de dos formas, por una parte en función de su diseño y por otra en
función de su ubicación.
2.2.1. Diseño
2.2.1.1. Software a medida
Se trata de un software hecho especialmente para la empresa en función de sus necesidades.

Suele ser más costoso que adaptar una herramienta ya creada. Como ventaja, al ser un software
realizado únicamente a partir de los requisitos empresariales, sólo dispondrá de aquellas
herramientas que sean útiles para la empresa y no más.
2.2.1.2. Solución estándar
Es la opción que utilizan la mayoría de empresas, se trata de adaptar un software, realizado por
uno de los fabricantes del sector a las necesidades de la empresa donde se vaya a implantar. En
este caso hay que estudiar de todas las soluciones que hay en el mercado cuál es la que mejor se
adapta a las necesidades de la empresa y qué módulos necesita la empresa para elegir el ERP
idóneo. Una vez elegido el ERP que mejor encaje con sus necesidades habrá que adaptarlo a sus
particularidades.
ERP horizontal o generalista
Es un ERP pensado para realizar las tareas más comunes en cualquier empresa. En él aparecen
los módulos más comunes, que utilizan la mayoría de empresas, por eso suelen ser los más
empleados.
ERP vertical
Es un ERP pensado para un determinado sector. Estará adaptado a las particularidades de dicho
sector. Por ejemplo un ERP dedicado a fábricas del sector cerámico, tendrá características que
sólo se utilizan en este tipo de empresas.
2.2.2. Ubicación
En función de donde están instalados los sistemas ERP se pueden clasificar en:
• ERP locales. Corresponde cuando el sistema está instalado en los propios servidores de la
empresa.
• ERP en la nube o SaaS. La mayoría de empresas están apostando por este tipo de
servicios que presentan una serie de ventajas frente al modelo local. Sus características
principales son las siguientes:
Menor tiempo de implantación del ERP. No se necesita preocuparse por el hardware

que va a correr la aplicación.
Servicio de subscripción. No hay que comprar licencias de las aplicaciones.
Ahorro en infraestructura: no se necesita realizar inversiones en servidores, sistemas

operativos, bases de datos, antivirus, sistemas de copias de seguridad y personal de
sistemas.
Permite el acceso desde cualquier lugar y multiplataforma. El acceso suele realizarse a

través de navegador web. Facilitando la colaboración entre usuarios del sistema.
Mayor facilidad de actualización.
2.3. Implantación de un ERP
La implantación de un ERP en una empresa implica un cambio trascendental en el funcionamiento

de los distintos procesos que la integran. En primer lugar, es muy importante tomar el tiempo
necesario para realizar una planificación correcta. Cuánto mejor se haga la planificación menos
imprevistos, sobrecostes y errores aparecerán en todo el proceso. Un método bastante utilizado
suele ser emplear una semana de planificación por cada mes estimado en la implantación. Hay
que crear un buen ambiente frente al cambio, con una actitud positiva en el personal, así como,
asignar responsables de la implantación que tengan la autoridad suficiente dentro de la empresa.
El objetivo de la implantación de un ERP es mejorar los procesos clave, obtener una mejor
eficiencia y menores costes. Por este motivo, hay que definir los indicadores clave (KPIs) para que
se pueda comprobar si los cambios realizados consiguen obtener las metas propuestas. En el
proceso de implantación no sólo interviene el proveedor encargado de la adaptación del software.
También se necesita el apoyo y tiempo del personal de la empresa donde se va a implantar, que
ayudará a replantear cada uno de los procesos operativos de cada área funcional. Por este motivo,
se deberá de liberar de carga de trabajo al personal que colabora con la empresa que implanta el
ERP.
Las fases en las que se puede dividir en proceso de implantación son las siguientes:
• Estudio de la situación actual y necesidades de mejoras.
• Definición del ERP conforme al análisis de requisitos y necesidades.
• Diseño y programación de la herramienta.
• Implantación.
• Formación.
• Puesta en marcha.
• Transición.
• Mantenimiento y seguimiento.
2.4. Ejemplos de software ERP
Las principales ventajas de utilizar software propietario son las siguientes:
• Suelen estar desarrolladas por empresas dedicadas al desarrollo de software que pueden
dedicar grandes cantidades de recursos.
• Sistemas probados en departamentos de control de calidad.
• Mayor capacidad de adaptación, módulos para conseguir mayor público objetivo.
• Mejor servicio postventa.
• Servicio de atención al cliente.
• La compañía que crea el software tiene empresas colaboradoras especializadas en

implantar el programa.
Algunos ejemplos de software ERP:
• SAP: Samsung Electronics Co., Penteo, Indra, IBM, Fujitsu, Deloitte, HP y Everis.
Este sistema ha sido integrado en miles de organizaciones a nivel mundial ofreciendo
nuevas oportunidades de negocio e internacionalización. Sus principales características
son:
La información está organizada jerárquicamente. Permite el acceso a la información

desde distintas perspectivas.
Toda la información se comparte entre los diferentes módulos y áreas del software. De
esta forma todos los usuarios con la correspondiente autorización podrán acceder a
ella.
Sistema en la nube (opcionalmente). Se puede acceder a la información de forma

remota.
• Microsoft Dynamics ERP: Carrefour, Revlon, Dell y Sephora. Posee soluciones para
pequeñas y medianas empresas (Microsoft Dynamics NAV), como para grandes
organizaciones internacionales (Microsoft Dynamics AX). Según datos del último evento
Convergence 2014 de Microsoft, 221.500 empresas en todo el mundo utilizan Microsoft
Dynamics en sus diversas ediciones. Sus características principales son las siguientes:
Herramientas para gestión financiera, cadena de suministro, fabricación y operaciones.
Servicios en la nube o en servidores propios.
Integración de aplicaciones finanzas, ventas y operaciones con la suite ofimática

Office.
• Oracle ERP también conocido como E-Business Suite: Kellogg’s, Kraft Heinz, Mazda,
Pandora y General Motors. Surge a partir de la adquisición de JD Edwards y PeopleSoft
por Oracle. Su funcionabilidad de contabilidad y finanzas se considera una de las mejores
del mercado. Estas son sus principales ventajas:
Gran desarrollo de la gestión de las bases de datos. Utiliza bases de datos Oracle que
incluye tecnología in-memory: permite acceso más rápido, simplificación de cálculos y
análisis en tiempo real.
Gran capacidad de gestión de operaciones contables y financieras.
Buenas funcionalidades para gestión de operaciones de producción.
Tiene la opción de ser contratado en la nube.
Permite el acceso a través de cualquier dispositivo.
Incluye un módulo de Business Intelligence.
• Sage X3: Grupo Winterman, Bonnysa, Arania y Coselva. Solución de gestión para
medianas empresas de los sectores fabricación, servicios y distribución. Sus principales
características son las siguientes:
Integración bidireccional (exportar/importar datos) con herramientas Office.
Permite el acceso a los datos a través de dispositivos móviles.
Permite control y seguimiento sobre procesos en tiempo real.
Herramientas business intelligence y creación de informes.
ERP en la nube y acceso a través de interfaz web.
Algunas de las ventajas del software ERP libre son que es más económico, se dispone del código
fuente de la aplicación, se puede distribuir, se dispone de personal cualificado se puede adaptar a
nuestras necesidades sin tener que partir de cero y ante un problema se puede consultar posibles
soluciones realizadas en la comunidad de desarrollo de la aplicación.
• Apache OFBiz: United States Air Force, Snaidero, British Telecom y Citigroup Procurement
System. Producto de código abierto para la automatización de los procesos empresariales.
Ofrece una gran cantidad de funcionalidades entre las que podemos destacar:
Gestión campañas de marketing, promociones y precios.
Administración de pedidos.
Gestión clientes.
Gestión almacenes y stock.
Gestión contable y financiera.
Administración de procesos.
• Compiere: Pharma Nord, OSG, La Poste y ISO. Fue la primera solución ERP de código
abierto del mercado. Desarrollado por Jorg Jank, ex director de desarrollo de Oracle. Su
desarrollo fue a partir de las necesidades de Goodyear en 1999. Administra los principales
procesos de negocio:
Compras.
Ventas.
Stock.
Facturación.
Finanzas.
Producción.
• Odoo (anteriormente OpenERP): Hospital de León, Ticketea y Agatha Ruiz de la Prada. Es

un conjunto de aplicaciones que abarca mucho más que un ERP. Integra nuevas
funcionalidades web como un CMS (gestor de contenidos web), blog, módulo de comercio
electrónico y funcionalidades de marketing online. Por este motivo se ha cambiado el
nombre de OpenERP a Odoo. Cubre las necesidades de las siguientes áreas:
Contabilidad y finanzas.
Compras y ventas.
Recursos humanos.
Gestión de proyectos.
Gestión de almacenes.
Marketing.
TPV.
CRM.
Fabricación.
• Openbravo: Grupo Eulen, Saic, Johnson Controls, Etam y Universidad Politécnica de

Madrid. Software de gestión empresarial libre creado en 2001 en Pamplona a partir del
ERP Compiere. Es uno de los ERP de código abierto más populares entre pequeñas y
medianas empresas. Sus principales características son las siguientes:
ERP en la nube y acceso a través de interfaz web.
Multiplataforma.
Posee cientos de extensiones para personalizar.
Interfaz muy intuitiva.
Implantación más económica respecto otros ERP.
Se puede obtener más información de cada uno de ellos en su correspondiente página web.
2.5. Diferencias entre CRM y ERP
Como ya se ha comentado anteriormente, el CRM se utiliza para mejorar todos los servicios que se
ofrecen al cliente. Es un conjunto de estrategias que nos permitirá entender mejor a nuestro
cliente, conocer sus necesidades, fidelizarlo y atraer a nuevos clientes. Para ello se necesitará
recoger una gran cantidad de información. Este conjunto de estrategias se apoyan fuertemente en
el software, ya que, los datos recogidos del cliente se van a almacenar en bases de datos, que
serán explotadas en el futuro para realizar tareas como pueden ser campañas de marketing, que
traerán nuevas ventas a la empresa.
En cambio el ERP es un conjunto de herramientas utilizadas para la gestión del negocio. Estas
herramientas están divididas en módulos que pueden ser módulo de producción, contabilidad,
stock, ventas, recursos humanos, etc.
Los distintos CRM y ERP pueden variar mucho en función de la empresa proveedora del software,
tipo de programa y empresa que utiliza el sistema. Aunque cabe resaltar que se encontrará
siempre los siguientes aspectos diferenciadores entre los dos términos:
• CRM se usa para tareas de front office como pueden ser campañas de marketing, todo lo
relacionado con el proceso de ventas (por ejemplo informes de ventas, productos más
vendidos), clientes, servicio de atención al cliente.
• ERP está más enfocado a la realización de tareas back office como son gestión y
administración de la actividad empresarial, contabilidad, finanzas, nóminas, recursos
humanos, optimización de tareas, reducción de gastos, estudiar flujos de información
dentro de la empresa, informes gastos y beneficios, mejorar plan de negocio.
• Tanto los sistemas CRM como los ERP almacenan toda la información en bases de datos.
Hoy en día se pueden encontrar sistemas que integran ambas soluciones en uno,
permitiendo contener toda la información en un sólo sistema que podrá mejorar los
resultados obtenidos por los sistemas aisladamente.
3. Beneficios y usos
3.1. Beneficios CRM
Como ya se ha comentado, el CRM gira alrededor del cliente por tanto todas las ventajas que
obtendremos del uso del CRM estarán relacionas con el cliente. Las principales ventajas del uso
del CRM son las siguientes:
• Datos unificados del cliente: se evitan posibles errores que pueden ocurrir al tener
sistemas diferentes de almacenaje de datos.
• Creación de estudios de mercado que permitirán realizar futuras estrategias de venta.
• Gestión y administración de ventas. Ventas verticales y ventas cruzadas: en función del

tipo de compras que realice un cliente se le pueden ofrecer productos relacionados con el
tipo de compras que suele realizar.
• Búsqueda de nuevas oportunidades de negocio. Estudios de clientes potenciales,

segmentación de mercado y público objetivo que permitirá conocer posibles futuras ventas.
• Generación de informes: Información para generación ofertas personalizadas. Se conoce

qué productos compra cada cliente, cuándo compra, qué necesidades tiene mejorando la
satisfacción de los clientes que servirá para tener previsión en almacén para futuras
demandas. Ayuda a que los comerciales puedan realizar mejor su trabajo, pues les ayuda
a conocer mejor los clientes.
• Descubrir nuevas oportunidades de negocio.
• Mejorar las relaciones con los clientes, reforzando su confianza y fidelizándolos.
• Descubrir nuevas tendencias de mercado.
3.2. Beneficios ERP
Los sistemas ERP permiten la adaptación a las necesidades de cada empresa. Para ello a partir de
una especificación de requisitos, técnicos implantadores se encargan de adaptar el software a las
particularidades correspondientes. Hay que tener en cuenta que el proceso de instalación,
adaptación y uso de este tipo de sistemas suele ser caro económica y temporalmente, pero a largo
plazo los beneficios obtenidos merecen la pena. Éstos son los siguientes:
• Automatización de tareas: muchas de las tareas realizadas repetitivamente en la actividad

empresarial se pueden automatizar en los sistemas ERP, produciendo un ahorro en costes,
que permitirá a los empleados ser más eficientes, se reducirán errores y realización de
tareas duplicadas consiguiendo un mayor beneficio y un aumento de la capacidad
operativa.
• Toma de decisiones en tiempo real a partir de cuadros de mando e informes generados a

través del ERP.
• Los datos son almacenados en un único sistema, permitiendo ser más eficientes frente a
cualquier imprevisto. Se tendrá un mayor control y trazabilidad de todas las transacciones
realizadas y producidas por la actividad empresarial, facilitando la tarea de realizar
estimaciones y previsiones.
• Control del flujo de datos empresarial. Mejora de la comunicación interna

interdepartamental.
• Son sistemas modulares, si en cualquier momento se necesita otro modulo se puede

implantar facilitando el crecimiento empresarial.
Brunetta, Hugo (2016). CRM-La guía definitiva: Estrategia de gerenciamiento de la relación con los
clientes. Pluma Digital Ediciones.
Greenberg, Paul (2008). CRM. Gestión de relaciones con los clientes. McGraw-Hill Interamericana
de España S.L.
Baran, Roger J., Galka, Rober J. (2013). CRM: The foundation of Contemporary Marketing
Strategy. Routledge.
Ptak, Carol A., Schragenheim, Eli (2016). ERP: Tools, Techniques, and Applications for Integrating
the Supply Chain.CRC Press.
Valle, A., Puerta, A. (2015) .Curso de Consultoría TIC. Gestión, Software ERP Y CRM.
Createspace.
Muñiz Gonzalez, L. (2007). ERP: Guía práctica para la selección e implantación. Gestión 2000.
http://www.crmespanol.com/crmdefinicion.htm
http://www.informatica-hoy.com.ar/camaras-digitales/Los-softwares-CRM-mas-utilizados.php
http://grupo05ulima.blogspot.com.es/2006/10/crm-analtico-operacional-y.html
http://www.evaluandocrm.com/tipos-de-crm/
http://www.dataprix.com/articulo/erp/que-modulos-imprescindibles-debe-incluir-erp
http://www.sistemasdegestion.com/index.php/productos/microsoft-dynamics-erp/modulos-
destacados/
http://smallbusiness.chron.com/types-erp-5161.html
http://www.yourerpsoftware.com/content/28-tipos-de-sistemas-erp
http://www.dataprix.com/articulo/erp/erp-horizontal-o-vertical-que-necesita-tu-empresa
https://www.salesinsideinc.com
https://idatalabs.com
https://xtuple.com/solutions/who-uses-xtuple
https://www.it-exponent.com/caracteristicas-de-sugarcrm/
https://www.sumacrm.com/soporte/cacteristicas-crm
http://blog.hostgreen.com/?p=604
http://formatalent.com/listado-de-empresas-que-utilizan-sap-en-espana/
http://www.muycanal.com/2014/03/03/microsoft-dynamics
https://www.softwaredoit.es/sap-erp-caracteristicas-y-funcionalidades/sap-erp-caracteristicas-y-
funcionalidades.html
https://www.microsoft.com/es-es/dynamics/erp.aspx
https://www.oracle.com/
https://www.ticportal.es/temas/enterprise-resource-planning/proveedores-erp/erp-oracle
http://www.sage.es/
http://bonsaierp.com.au/general/who-is-using-ofbiz.html
http://noticias.iberestudios.com/openbravo-software-libre-gestion-erp-pymes/?especial=vanguardia
http://www.compiere.com
http://openerpspain.com/
http://abas-erp.com/es/news/4-pasos-para-preparar-una-implantaci%C3%B3n-erp-en-su-negocio
http://www.informatica-hoy.com.ar/software-crm/MySAP-CRM-Una-solucion-integral-de-software-
CRM.php
Tema 33. E-learning: Conceptos, herramientas,
implantación y normalización
Javier Pérez Bou

Colegiado 0007
En este capítulo comenzaremos remontándonos a los orígenes de la formación a

distancia en el siglo XVII y analizando los avances hasta nuestros días.
Revisaremos los diferentes términos empleados en la formación a distancia. Haremos

una revisión en profundidad del denominado triángulo del e-learning formado por
tecnología, contenidos y servicios. La aparición de nuevas tecnologías ha propiciado
formas diferentes de desarrollar contenidos al igual que la posibilidad de ofrecer
nuevos servicios. No existe una única modalidad de e-learning por lo que repasaremos
las diferentes opciones.
Estudiaremos la evolución de las plataformas que dan soporte a los Entornos Virtuales
de Aprendizaje, las herramientas que contienen y realizaremos una pequeña
comparativa entre algunas de las plataformas más extendidas.
Si resulta importante la plataforma, más lo es la forma de estructurar y desarrollar el

curso. El e-learning ha supuesto una revolución a nivel metodológico. Analizaremos
los diferentes métodos pedagógicos que se pueden utilizar para la elaboración de los
contenidos.
Veremos los servicios complementarios que junto con las plataformas y contenidos
son necesarios para obtener una formación de calidad y generar satisfacción tanto en
el alumnado como en el profesorado
Profundizaremos en la metodología ADDIE para la implantación de proyectos de

e-learning y en último lugar trataremos sobre la normalización haciendo especial
hincapié en SCORM.
“El éxito de un curso eLearning se puede resumir en una frase corta: lograr que los
participantes intervengan mucho y se diviertan. Y eso lo logra el talento humano, no
las máquinas ni el software. Lo logran los contenidos bien estructurados y el buen
diseño pedagógico, los buenos tutores que animan los foros, los profesores expertos
que saben tener empatía y consiguen que los alumnos se apasionen, sean proactivos
y participen. Al final, lo importante son las personas, movilizar el talento humano”.
Íñigo Babot
Javier Pérez Bou
1. Introducción
Hay un cierto consenso entre autores en considerar al profesor C. Philipps padre de la formación a
distancia puesto que en el siglo XVII utilizó la Gaceta de Boston para insertar un anuncio en el que
ofrecía lecciones escritas de cultura general mediante el envío por correo ordinario (1).
El empleo del correo ordinario para actividades relacionadas con la formación comienza en
paralelo a la comercialización de novelas editadas por entregas. Sucede en el siglo XIX,
comenzando en Francia, Dinamarca, Suecia, Noruega y Reino Unido. El abaratamiento del coste
de impresión y el transporte ferroviario actuaron a favor de esta forma de distribuir conocimiento.
(2).
Posteriormente, la evolución de la tecnología para el acceso y la gestión de la información ha

permitido una expansión considerable en la formación a distancia. Cabe destacar por un lado la
irrupción en los años 80 de los ordenadores personales y por otro lado la universalización del
acceso a Internet mediante la Web y el correo electrónico a finales del s.XX.
Montesinos resume los vectores tecnológicos en la siguiente tabla:
Tabla I. Evolución del sector de la Formación a Distancia desde sus orígenes hasta principios de la
segunda década del s. XXI. Fuente (2)
Etapa ¿Cuándo? Vectores Tecnológicos Caracterización de las
actividades
Orígenes S.XIX Imprenta, correo urbano e Correo postal, envío de
interurbano estable y materiales y evaluaciones.
transporte por ferrocarril. Actividades formativas no
Máquina de escribir. oficiales.
Despegue de la Segunda Regulaciones Nacionales Correo postal, envío de
Formación a mitad del (oferta pública). materiales y evaluaciones.
Distancia S. XX Actividades formativas con
reconocimiento oficial. Apoyo de
la Admón. Pública a este
formato.
Aparición de la 1980- Ordenador Personal (PC) y Edición de Videodiscos
enseñanza mediados abaratamiento de los medios interactivos, materiales
asistida por los 90 de impresión doméstico. instructivos basados en CD y
ordenador videos adaptados al PC. Altos
costes de estampación y edición.
E learning: Conceptos, herramientas, implantación y normalización
Etapa ¿Cuándo? Vectores Tecnológicos Caracterización de las

actividades
Aparición del 1990-2000 Aparición de la tecnología Las Universidades presenciales
e.learning WEB basada en HTML y empiezan a explorar el uso de
generalización del uso de Internet para compartir
Internet en el ámbito materiales de formación (reglada
profesional. Generalización del y permanente) con los discentes.
uso del correo electrónico en Servidores de correo gratuitos.
ámbitos laborales y comienzo
del uso doméstico.
Generalización de la ofimática.
Despegue del 2000-2010 CMS (Content Management Estandarización del uso de
e.learning System), crecimiento del CMS. Producción de cursos para
ancho de Banda y Tecnología profesionales con formatos
móvil. Generalización de mixtos (distancia y
acceso WIFI en lugares semipresencial).
públicos a bajo coste. Acceso
ubicuo a la Red. Desarrollo de
los Smartphones.
Aparición del Principios Generalización de la Acceso a Internet universal a
“mobile-learning” segunda conectividad a internet bajo coste con medios móviles y
década doméstica y móvil con por WIFI. Primeras experiencias
s.XXI ordenadores portátiles. MOOC (Coursera, edX y
Tecnología Webinar. Udacity) y en España, la UNED
Generalización de los hace accesible material
Smartphones. Despegue de la formativo de forma gratuita.
tecnología Tablet y Phablets y Universia lanza la iniciativa
de la programación de APPs. Miriada.
En España, si bien existen antecedentes en el sector privado, es en el año 1962 cuando

formalmente aparecen experiencias de formación reglada a través del Bachillerato radiofónico.
García Aretio indica que “su sistema, que combina emisiones radiofónicas con textos escritos y
tutorías, se aplica en España desde 1963, con tan buenos resultados que ha sido adoptado en
otros quince países latinoamericanos y cuatro africanos” (3). La Ley General de la Educación de
1970 prevé la creación y regulación de las “modalidades de enseñanza por correspondencia, radio
y televisión” creándose en 1972 la UNED (Universidad Nacional de Educación a Distancia). En
1975 y en 1979 se crean el Instituto Nacional de Bachillerato a Distancia (INBAD) y el Centro
Nacional de Educación Básica a Distancia (CENEBAD), respectivamente. Con la puesta en marcha
de la Ley Orgánica de Ordenación General del Sistema Educativo de España (LOGSE), en 1992
ambos se refunden en el Centro para la Innovación y Desarrollo de la Educación a Distancia
(CIDEAD). En cuanto a la iniciativa privada de Formación a Distancia, en 1977 se crea en España
ANCED, la Asociación Nacional de Centros de E-learning y Distancia.
Javier Pérez Bou
En 1998, la UNESCO en el Informe Mundial sobre la Educación, “Los docentes y la enseñanza en

un mundo en mutación”, describió el impacto de las Tecnologías de la Informática y las
Comunicaciones en los métodos de enseñanza-aprendizaje, su transformación y la forma de
acceder al conocimiento por docentes y estudiantes señalando que: “en el área educativa, los
objetivos estratégicos apuntan a mejorar la calidad de la educación por medio de la diversificación
de contenidos y métodos, promover la experimentación, la innovación, la difusión y el uso
compartido de información y de buenas prácticas, la formación de comunidades de aprendizaje y
estimular un diálogo fluido sobre las políticas a seguir. Con la llegada de las tecnologías, el énfasis
de la profesión docente está cambiando desde un enfoque centrado en el profesor que se basa en
prácticas alrededor del pizarrón y el discurso, basado en clases magistrales, hacia una formación
centrada principalmente en el alumno dentro de un entorno interactivo de aprendizaje” (4).
Lupion señala en su informe “La Educación Superior a Distancia en América Latina y el Caribe” de
2010, que los incrementos de crecimiento en la matrícula de las actividades a distancia y
semipresenciales es superior al 25% interanual frente a un 3% de las actividades presenciales, (5).
Garrison (6) señala que la información disponible en Internet se multiplica en factores del 200%
diariamente, pero la información no es formación, forma parte del proceso, pero los factores que
participan, además de los propios materiales, son, entre otros:
• La tutorización de un experto.
• La autoevaluación.
• La certificación.
• La interacción desde dispositivos móviles.
• El prestigio de la entidad que certifica.
Especialmente con las personas “nativas digitales” que han nacido utilizando estas tecnologías,
Garrison indica que el potencial de crecimiento de esta modalidad de enseñanza es incalculable.
En el Blog “Origin Learning” aparece un post con el título “20 Facts about e-learning” en el que se
indica que para el año 2020 se espera que el mercado de e-learning global sea de 37.8 billones de
dólares (7).
2. Conceptos
De acuerdo con las propuestas de diferentes autores, García y Cabrero (8) definen como
e-learning la formación apoyada en la presentación de contenidos a través de Internet y que utiliza
diferentes herramientas de comunicación sincrónicas y asincrónicas para establecer la interacción
entre docente y discente.
Cabero (9) indica que los entornos de formación que permiten interaccionar de forma asíncrona,
deben contemplar una serie de funcionalidades entre las que podemos destacar:
• Ofrecer una plataforma de comunicación lo más rica y variada posible, incorporando

herramientas de comunicación sincrónica.
• Incorporar zonas para el debate (síncrono o asíncrono).
• Utilización de guías visuales que faciliten la percepción al estudiante del recorrido

curricular seguido en su proceso de formación.
• Ofrecer al estudiante la posibilidad de poder elegir el recorrido de aprendizaje, sistemas

simbólicos y el tipo de material ajustado a su estilo de aprendizaje.
• Apoyarse en principios fáciles de interpretar para el seguimiento e identificación del

entorno.
• Utilizar formas de presentación multimedia.
• Incorporar zonas para la comunicación verbal, auditiva o audiovisual con el profesor.
Por su parte, García Aretio (10) especifica las cuatro características que debe tener el e-learning:
• Separación física docente y discente.
• El estudio independiente por parte del alumno.
• Comunicación e interacción entre los participantes en el acto instruccional mediante

diferentes herramientas de comunicación sincrónicas y asincrónicas.
• La existencia de un soporte institucional.
A modo de resumen, García Peñalvo (11) define e-learning como la capacitación no presencial
que, a través de plataformas tecnológicas, posibilita y flexibiliza el acceso y el tiempo en el proceso
de enseñanza-aprendizaje, adecuándolos a las habilidades, necesidades y disponibilidades de
cada discente, además de garantizar ambientes de aprendizaje colaborativos mediante el uso de
herramientas de comunicación síncrona y asíncrona, potenciando en suma el proceso de gestión
basado en competencias.
Igualmente hace mención al triángulo del e-learning formado por:
• Tecnología (plataformas, campus virtuales…).
• Contenidos (calidad y estructuración de los mismos se toman como elementos capitales

para el éxito de una iniciativa de e-formación).
Javier Pérez Bou
• Servicios (engloba la acción de los discentes, elementos de gestión, elementos de

comunicación, elementos de evaluación…).
La realidad es que las posibilidades de emplear las herramientas y técnicas de e-learning también
en la formación presencial han permitido crear tres grandes modelos formativos que resumimos en
el siguiente cuadro:
Tabla II. Modelos Formativos apoyados en e-learning. (12)

Modelo de enseñanza presencial Modelo semipresencial o de Modelo a distancia o de
con apoyo de Internet blended learning educación on line
Internet y específicamente el aula Integración y mezcla de Titulaciones on line
virtual es un complemento o clases presenciales con (asignaturas, cursos,
anexo a la docencia presencial. A actividades docentes en aula máster, doctorado)
veces se utiliza el aula virtual en virtual. ofertados a distancia través
salas de informática bajo de campus virtuales.
supervisión del docente. En otras
ocasiones el aula virtual es un
recurso de apoyo para el estudio
del alumno en su hogar.
Se mantiene el modelo No hay diferenciación nítida Apenas hay encuentro físico
presencial de docencia: en entre procesos docentes o presencial entre alumnos
horarios y en aulas tradicionales. presenciales y virtuales. y profesores. Casi toda el
Existe un continuum en el proceso educativo es a
proceso educativo. distancia.
En este modelo se utiliza el aula Se innova el modelo Lo relevante son los
virtual de forma similar a una presencial de docencia: en los materiales didácticos y el
fotocopiadora: para que los horarios, en los espacios y en aula virtual.
estudiantes tengan acceso a los los materiales.
apuntes/ejercicios de la
asignatura.
El aula virtual se concibe como El aula virtual es un espacio Cobra mucha importancia la
un espacio de información: se para la información, la interacción social entre los
ofrece programa asignatura, actividad de aprendizaje y la estudiantes y el docente
horarios, tutorías, calificaciones, comunicación entre mediante los recursos
apuntes, etc. Existe poca profesores y alumnos. virtuales.
comunicación e interacción social
a través del aula virtual.
Podemos considerar que las ventajas que nos proporcione el empleo del e-learning son:
• Disminuye o elimina el grado de presencialidad física del alumno en el aula. Favorece a los
colectivos que no tienen la posibilidad de acceder a la formación presencial.
• Permite flexibilidad horaria para el desarrollo de los contenidos asíncronos. El alumno

decide el cuándo. Esto aumenta el nivel de autonomía y de responsabilidad del alumno.
• Permite un mayor número de destinatarios. Tanto porque evita las limitaciones de las aulas
presenciales, como porque la promoción puede llegar a usuario de todo el mundo.
• Mayor interacción docente-alumno. Existen muchas herramientas (chat, foros, correo

electrónico, videoconferencias) que facilitan la comunicación docente-alumno y alumno-
alumno.
• Permite el acceso a un mayor número de fuentes y datos de los ofrecidos por el docente,
en cualquier momento y en cualquier lugar.
• Pone a disposición de alumnos y docentes la posibilidad de compartir gran cantidad de

recursos multimedia de todo tipo que facilitan la adquisición de competencias por parte del
alumno y el registro de las evidencias de aprendizaje por parte del docente.
• Mejora la accesibilidad a personas con algún tipo de discapacidad mediante el uso de

dispositivos adaptados.
Un caso especial de e-learning son los MOOC (masive open on-line courses) por sus siglas
anglosajonas. Se trata de cursos diseñados para grupos con un elevado número de alumnos, en
abierto (gratuitos) y online. Por sus características son cursos asíncronos y con poca o nula
tutorización. Tamar Lewin describió en julio de 2012, en el New York Times (13) el terremoto que
estaba suponiendo la organización de Formación a Distancia ofertada de manera gratuita por parte
de las Universidades Estadounidenses para públicos extensos y masivos.
La primera experiencia piloto privada con un curso de Inteligencia Artificial en Udacity recibió
160.000 inscripciones de 19 países.
El retorno de la inversión de estos cursos viene habitualmente por tres vías:
• Publicidad. Los datos de los alumnos son cedidos a empresas, obteniendo ingresos por
ello.
• Certificación. Los alumnos que deseen obtener una certificación de la institución deben
realizar un pago por ella. Habitualmente se exige la superación de alguna prueba para
evaluar los conocimientos adquiridos.
• Servicios Premium tales como tutorías, contenidos adicionales, etc.
Un antecedente a los MOOC son los OpenCourseWare (OCW). Se trata de poner en abierto y
cediendo algunos de los derechos de autor, los materiales que van a ser utilizados por los alumnos
de formación presencial. Esta práctica es puesta en marcha por el MIT en el año 2001 creándose
en el año 2005 el Openware Consortium.
Javier Pérez Bou
3. Herramientas. El triángulo del e-learning
García Peñalvo (11) y otros autores referencian a Lozano (14), estableciendo las tres partes
esenciales del e-learning: tecnología, contenidos y servicios.
3.1. Tecnología
El núcleo central de la tecnología lo constituye la plataforma de teleformación o campus virtual. Se

trata del entorno hardware y software que permite gestionar el desarrollo de las actividades
formativas. El origen del término viene de los LMS (Learning Management System). Los LMS están
más centrados en la gestión de la interacción con los usuarios que en la orientación pedagógica de
los contenidos. En la medida en que ha aumentado el número y origen de los recursos disponibles
ha irrumpido junto al LMS los gestores de contenidos o CMS (Content Management System)A. La
conjunción de las ventajas de ambos sistemas dieron lugar a los que se conoce como LCMS
(Learning and Content Management System), plataformas de e-learning o campus virtuales que
proporcionan los Entornos Virtuales de Aprendizaje (EVA) (15). Boneu subraya, que las
plataformas son un conjunto de funcionalidades que deben tener cuatro características
fundamentales: interactividad, flexibilidad, escalabilidad, y estandarización.
Por otra parte, estas plataformas pueden incluir todo un conjunto de herramientas capaces de
proporcionar soporte tanto a las actividades formativas como a los procesos de negocio de la
formación.
Tabla III. Herramientas potenciales que pueden estar incluidas en una plataforma para el
e-learning (15).
Tipo Herramienta
Herramientas orientadas • Foros
al aprendizaje • Buscador de foros
• e-portafolio
• Intercambio de archivos
• Soporte de múltiples formatos de archivos, como por
ejemplo HTML, PDF, Word, Excel, Acrobat, entre otros
• Herramientas de comunicación síncrona (chat): para el
intercambio de mensajes entre los participantes
• Herramienta de comunicación asíncrona (correo electrónico,
mensajería)
• Servicios de presentación multimedia (videoconferencia,
vídeo, pizarra electrónica, entre otros)
• Diario (blogs)
• Blogs de asignaturas
• Weblogs individuales de alumnos
• Weblogs grupales de alumnos
• Wikis
Tipo Herramienta
Herramientas orientadas • Anotaciones personales o favoritos (bookmarks)
a la productividad • Calendario y revisión del progreso
• Ayuda en el uso de la plataforma
• Buscador de cursos
• Mecanismos de sincronización y trabajo fuera de línea
• Control de publicación, páginas caducadas y enlaces rotos
• Noticias del lugar
• Avisos de actualización de páginas, mensajes a foros y
envío automático
• Soporte a la sindicación de contenidos (RSS, News,
PodCast, etc.)
Herramientas para la • Grupos de trabajo
implicación de los • Autovaloraciones
estudiantes • Rincón del estudiante (grupos de estudio)
• Perfil del estudiante
Herramientas de soporte • Autenticación de usuarios
• Asignación de privilegios en función del rol del usuario
• Registro de estudiantes
• Auditoría
Herramientas destinadas • Tests y resultados automatizados
a la publicación de • Administración del curso
cursos y contenidos • Apoyo al creador de cursos
• Herramientas de calificación en línea
• Seguimiento del estudiante
Herramientas para el • Conformidad con la accesibilidad
diseño de planes de • Reutilización y compartición de contenidos
estudio • Plantillas de curso
• Administración del currículum
• Personalización del entorno (look and feel)
• Herramientas para el diseño de la educación
• Conformidad con el diseño de la educación (estándares IMS,
AICC y ADL)
Sistemas/Herramientas • Sistemas integrales de conocimiento
para la gestión del • Los sistemas mediadores de información
conocimiento en el • Librerías digitales o repositorios
ámbito educativo • Sistemas basados en ontologías
• Sistemas basados en folksonomías (en el contraste con
"taxonomía") es una indexación social, la clasificación
colaborativa por medio de etiquetas simples en un espacio
de nombres llano, sin jerarquías ni relaciones de parentesco
predeterminadas.
Javier Pérez Bou
Recientemente, (16), han realizado una comparativa entre siete entornos LMS open source (A-
View es open source sólo en la India) evaluando la cantidad y calidad de las herramientas que
incluyen.
Tabla IV. Comparación de características de comunicación (16). Elaboración propia.

Plataforma
Características Moodle Dokeos eFront Ilias Sakai Olat A-View
Blogs S S S S S S S
Foros S S S S S S S
Intercambio de S S S S S S S
Archivos
Chat S S S S S S S
Wiki S S S S S S S
Herramientas S S N S S N S
colaborativas
Pizarras o S N S S N S S
pantallas táctiles
Compartir S S S S S S S
documentos
Subir tareas S S S S S S S
Email S S S S S S S
Votaciones N N N S N N S
Puntuación 90.9 81.8 81.8 100 81.8 81.8 100
Tabla V. Comparación de características de productividad (16). Elaboración propia.

Plataforma
Generación de S S S S S S S
informes
Gestión de recursos S S S S S S S
Biblioteca digital S N S N N N S
Programación del N S S S N N S
profesor
Calendario académico S S N S N S S
Compatible con S S S S S S S
dispositivos móviles
Glosario S S S S S N S
Puntuación 85.7 85.7 85.7 85.7 57.1 57.1 100
Tabla VI. Comparación de características de desarrollo de los cursos (16). Elaboración propia.
Plataforma
Blended Learning S N S N S S S
Aulas virtuales S N S S N N S
Multilenguaje S S S S S S S
Gestión de cursos S S S S S S S
Gestión de S S S S S S S
contenidos
Evaluaciones del S S N S N S S
curso
Cuestionarios / S S S S S S S
Encuestas
A su propio ritmo S S S S S S S
Capacidades S S S S S S S
multimedia
Gráficos S S S S S S S
Puntuación 100 80 90 90 80 90 100
Tabla VII. Comparación de características de administración de usuarios (16). Elaboración propia.

Plataforma
Autenticación S S S S S S S
Control de S S S S S S S
acceso a los
usuarios
Usuarios S S S S S S S
ilimitados
Gestión del S N S S S S S
registro de
usuarios
Informes S S S S S S S
administrativos
Puntuación 100 80 100 100 100 100 100
Javier Pérez Bou
Tabla VIII. Comparación de plataformas (16). Elaboración propia.

Plataforma
Comunicación 90.9 81.8 81.8 100 81.8 81.8 100
Productividad 85.7 85.7 85.7 85.7 57.1 57.1 100
Desarrollo 100 80 90 90 80 90 100
Administración 100 80 100 100 100 100 100
de usuarios
Puntuación 94.15 81.88 89.34 93.92 79.74 82.24 100
promedio
Si bien esta comparativa viene condicionada en parte porque A-View es utilizado por varias
Universidades de la India y los investigadores también lo son, cabe destacar que precisamente son
los países asiáticos los que mayor número de alumnos utilizan la formación a distancia.
Tabla IX. Selección de Universidades a Distancia Tradicionales (2).

PAIS NOMBRE Creación Nº alumnos-2011
Pakistán Allama lqbal Open University 1974 3.2 millones
India Indira Gandhi National Open University 1985 3 millones
China Open University of China 1979 2.7 millones
Turbia Anadolu University 1982 884.081
Bangladesh Open University of Bangladesh 1992 600.000
Indonesia Universitas Terbuka 1984 646,467
EEUU University of Phoenix 1976 346.000
España Universidad Nacional de Educación a 1972 260.000
Distancia
Korea Korean National Open University 1982 210.978
Gran Bretaña The Open University 1969 203,744
Iran Payarne Noor University 1987 183.000
Thailand Sukhothai Thammathirat OU 1978 181.372
Igualmente, en esa comparativa no aparecen otros LMS de gran uso como puedan ser ATutor en el
caso de open source o Blackboard en el caso de plataformas de pago.
3.2. Contenidos
La calidad y estructuración de los mismos son claves para el éxito del e-learning. Antes de la era
Internet, los contenidos a distancia estaban formados por folletos o libros en papel y en ocasiones
discos, cd’s o cintas de audio que el alumno adquiría y estudiaba por su cuenta. Habitualmente
disponía de un número de teléfono al que contactar para tutorías o resolución de dudas y una
dirección de correo a la que remitir los ejercicios y tareas a resolver.
La puesta en marcha de la tecnología desarrollada en el punto anterior, ha permitido simplificar

todo este proceso permitiendo al alumno disponer de los contenidos en el momento que requiere y
desde el lugar donde se encuentre. Igualmente permite capacidades multimedia mucho más
avanzadas que los simples documentos manuscritos o archivos de vídeo y audio.
Las entregas pueden hacerse mediante la propia plataforma y el alumno debe ser consciente en
todo momento de su evolución gracias a la planificación de las actividades formativas, el desarrollo
de evaluaciones y los informes de progreso que proporciona la propia plataforma.
Es por ello que cambia el modelo de aprendizaje y los contenidos deben ser adaptados a este
nuevo modelo.
El uso de la Web 2.0 en los procesos de aprendizaje a distancia y de e-learning ha generado el

concepto de Aprendizaje 2.0 al que Bolivar (17) caracteriza con las siguientes características:
1. Enredado. Es fundamentalmente un aprendizaje en red.
2. Conversacional. La red propicia y fomenta las conversaciones entre los participantes de las
actividades formativas.
3. Distribuido. La transferencia de conocimiento no es jerárquica ni unidireccional

difuminándose los roles de docente y discente pudiendo ser intercambiados en
circunstancias concretas.
4. Colaborativo. El conocimiento surge de las múltiples aportaciones y conversaciones de los

participantes.
5. Líquido. El proceso de generación de conocimiento es continuo, estando en una “beta

permanente”
6. Abierto. El valor de la información no consiste en protegerlo sino en compartirlo
7. Informal. El aprendizaje es autoliderado y autorregulado produciéndose de forma

espontánea
8. Ubicuo. No sólo es en cualquier momento y lugar. Las posibilidades de dispositivos y

herramientas como la realidad aumentada sobrepasan las capacidades de la enseñanza
tradicional
9. Personalizado. La gestión del conocimiento pasa a ser una responsabilidad individual.
10. Híbrido. Se rompen las barreras de las disciplinas tradicionales permitiendo integrar
conocimiento de áreas diferentes (ej.: Bioinformática) dando lugar a la cultura de remezcla
(mashup).
Por otra parte, el Aprendizaje 2.0 nos permite pasar (18):
Javier Pérez Bou
• De la recepción a la participación.
• Del control a la reflexión.
• De un enfoque centrado en productos, a otro en procesos para el desempeño y la

competencia.
• Hacia procesos de planificación educativa centrada en los alumnos.
• Del alumno receptor de la materia del aprendizaje, a un desarrollador de la misma.
• Y transformar las pruebas de rendimiento.
En una formación tradicional el esfuerzo se dirige hacia la mejora de las sesiones que se imparten,
mientras en el e-learning se debe poner un énfasis mayor en el diseño y la elaboración de
materiales estructurados que el discente pueda trabajar de manera autónoma y que sean aptos
para ser reutilizados.
Es importante recalcar que un curso bien diseñado puede ser ofertado muchas veces a diferentes
receptores utilizando los mismos contenidos. Igualmente, los componentes del curso (Objetos de
Aprendizaje Reutilizables o RLO en inglés), al ser autocontenidos, tienen la capacidad de ser
utilizados en distintos contextos, pudiendo ser incorporados en otros cursos. Por ejemplo, un
módulo de funciones básicas en Excel puedo ser utilizado en programas de contabilidad, recursos
humanos, gestión de aulas, etc.
Una vez definida la estructura del curso, el diseño debe especificar la mejor combinación de
métodos y técnicas para un curso e-learning determinado.
• Métodos expositivos. Ponen el énfasis en la forma de absorción de información.
• Métodos de aplicación. Tareas que realizan los alumnos mediante las cuales adquieren los
conocimientos.
• Métodos colaborativos. Motivan a los alumnos a compartir conocimientos realizando tareas

de manera colaborativa.
A continuación, se resumen los diferentes usos, formatos, ventajas y desventajas de los métodos
pedagógicos. En general, en cada proyecto de formación se emplean varios de estos métodos y
diferentes tipos de formatos.
Tabla X. Métodos expositivos. Fuente (19).

Método Usado para Formatos de Ventajas Desventajas
presentación
Presentaciones, Facilitar la Recursos Elaboración rápida No existe interactividad –

estudios de adquisición de pedagógicos simples aprendizaje pasivo
caso, ejemplos conocimientos (documentos o
desarrollados, (principalmente presentaciones en
demostraciones conocimientos PPT)
conceptuales y Lecciones de Flexible: permite el usoInteractividad de nivel
conocimientos e-learning interactivas de diversas técnicas bajo/medio – riesgo de
objetivos), pedagógicas que se convierta en
orientación, aprendizaje pasivo. Uso
motivación, correcto de técnicas
cambios de pedagógicas y elementos
actitud multimedia para evitar
riesgos
Webcasting Relativamente fácil de No existe interactividad –
(lecciones en video y desarrollar aprendizaje pasivo Debe
podcasts) tomarse en
consideración el tipo de
conexión a Internet con
que cuentan los alumnos
Webinars (video Permite la interacción El instructor debe estar
conferencia, audio entre el instructor y los preparado para enseñar
conferencia, basados alumnos. Requiere en línea y usar material
en el chat) poco esfuerzo para de apoyo adecuado.
convertir el material Debe tomarse en
Tabla XI. Métodos de aplicación. Fuente (19).

presentación
Método de Desarrollar Combinación de Permite a los alumnos Usado principalmente
demostración- habilidades de animación y practicar para software y
práctica procedimientos simulación operacional procedimientos médicos
simples
Aula virtual Debe tomarse en
(empleando el consideración el tipo de
intercambio de conexión a Internet con
aplicaciones) que cuentan los alumnos
Javier Pérez Bou

presentación
Material de Proporciona Documentos impresos Promover la Los sistemas expertos
apoyo para el información y tales como listas de transferencia del sofisticados requieren de
trabajo orientación en el verificación, glosarios aprendizaje al un diseño complejo
momento técnicos, plantillas, desempeño laboral
oportuno manuales
Sistemas de ayuda y
expertos en línea
Ejercicios Desarrollar Lecciones de Buen nivel de Se requiere de bastante
basados en habilidades e-learning interactivas interactividad tiempo para su diseño
casos cognitivas para un
Simulación electrónica Altamente interactivo Se requiere de bastante
trabajo específico
basada en escenarios tiempo para su diseño. El
ramificados costo de producción de
simulaciones multimedia
puede ser alto. Se
requiere el apoyo en
línea de un tutor o
instructor
Actividad individual Altamente interactivo + Se requiere de bastante
con tutor retroalimentación tiempo para su diseño.
personalizada Se requiere el apoyo
activo en línea de un
tutor o instructor.
Debe tomarse en
Actividad grupal en Altamente interactivo + Se requiere de bastante

línea dimensión social tiempo para su diseño.
Se requiere el apoyo
activo en línea de un
facilitador.
Debe tomarse en

presentación
Juegos de rol Desarrollar Lección de e-learning Buen grado de Se requiere de bastante
habilidades interactiva interactividad tiempo para su diseño
interpersonales.
Estimular Simulación electrónica Altamente interactivo Se requiere de bastante
cambios de basada en escenarios tiempo para su diseño. El
actitud ramificados costo de producción de
simulaciones multimedia
puede ser alto
Actividad grupal en Altamente interactivo + Se requiere de bastante
línea dimensión social tiempo para su diseño.
Debe tomarse en
que cuentan los
alumnos. Se requiere el
apoyo activo en línea de
un facilitador
Simulaciones y Adquirir un Simulaciones Altamente interactivo. Se requiere de bastante
juegos serios conocimiento simbólicas Permite practicar un tiempo para su diseño y
acabado de nivel alto de producción y tienen un
sistemas desempeño cognitivo alto costo. Se requiere el
complejos (aplicar, analizar) apoyo activo en línea de
un tutor o ET
Juegos didácticos Altamente interactivo. Se requiere de bastante

Permite practicar un tiempo para su diseño y
nivel alto de producción y tienen un
desempeño cognitivo alto costo. Se requiere
(aplicar, analizar) un diseño adecuado para
que sea efectivo. Se
requiere el apoyo activo
en línea de un tutor o ET
Investigación Construcción Foros de discusión, e- Permite practicar un Se requiere el apoyo

guiada activa de mail, chat, audio y nivel alto de activo en línea de un
conocimientos videoconferencias. desempeño facilitador para ofrecer
Wiki, blog, cognitivo(analizar, ayuda y
documentos crear) retroalimentación
compartidos
Trabajo en Construcción Foros de discusión, e- Permite practicar un Se requiere el apoyo
proyectos activa de mail, chat, audio y nivel alto de activo en línea de un
conocimientos videoconferencias. desempeño facilitador para ofrecer
Wiki, blog, cognitivo(analizar, ayuda y
documentos crear) retroalimentación
compartidos
Javier Pérez Bou
Tabla XII. Métodos colaborativos. Fuente (19).

presentación
Discusión Estimular el Foros de discusión, e- Permite la reflexión, Menos eficaz que el
guiada en línea pensamiento mail, chat, audio y socialización e trabajo en proyectos
crítico y la videoconferencias intercambio de colaborativos para
reflexión. Facilitar conocimientos alcanzar objetivos de
las aprendizaje. Debe
comunicaciones tomarse en consideración
entre los el tipo de conexión a
alumnos. Internet con que cuentan
Desarrollar los alumnos
habilidades
interpersonales.
Estimular
cambios de
actitud
Trabajo Estimular el Foros de discusión, e- Permite a los alumnos Se requiere el apoyo
colaborativo pensamiento mail, wiki, blog, chat, demostrar sus activo en línea de un
crítico y la audio y conocimientos de facilitador para ofrecer
reflexión. videoconferencias, manera explícita a ayuda y retroalimentación.
Desarrollar documentos través de la Debe tomarse en
habilidades para compartidos argumentación consideración el tipo de
la resolución de conexión a Internet con
problemas. que cuentan los alumnos
Desarrollar
habilidades
interpersonales.
Estimular
cambios de
actitud
Tutoría entre Estimular el Foros de discusión, e- Ideal para proyectos de Podría ser necesaria la
iguales pensamiento mail, wiki, blog, chat, capacitación para facilitación. Debe tomarse
crítico y la audio y docentes / instructores en consideración el tipo
reflexión. videoconferencias, de conexión a Internet
Desarrollar documentos con que cuentan los
habilidades compartidos alumnos
interpersonales.
Estimular
cambios de
actitud
A modo de decálogo, para la planificación y desarrollo de un proyecto docente en un aula virtual

deberíamos (12):
1. Crear espacios de conversación y comunicación permanentes: chat, foros, blogs, tutorías

virtuales, email, etc.
2. Plantear tareas que exijan un esfuerzo intelectual del alumno: leer, escribir, analizar,
buscar, reflexionar, elaborar, valorar, etc.
3. Combinar las tareas realizadas individualmente con las realizadas en grupo.
4. Establecer desde el inicio un calendario detallado de cada actividad, plazos de entrega,

fechas de evaluación, tareas, etc.
5. Incorporar guías y recursos para que el alumno pueda realizar autónomamente las
actividades (tutoriales y enlaces a documentos y ejemplos).
6. Estimular la motivación y fomentar la participación del alumnado (noticias curiosas, foro,

etc).
7. Añadir documentos de consulta en formatos variados (enlaces, vídeos, mapas

conceptuales, etc).
8. Mantener activo un tablón de publicación de noticias.
9. Establecer desde el inicio y públicamente los criterios de evaluación.
10. Una tutorización y feedback permanente entre el profesor y cada alumno.
3.3. Servicios
Lozano (14) establece como servicios “la acción de los tutores, profesores on-line, la
documentación que encontramos en la Biblioteca virtual, y todo un amplio abanico de posibilidades
desde el chat a la conexión on-line, que ayuda a desarrollar los múltiples modelos del e-learning”.
Este apartado engloba elementos variopintos necesarios para obtener un e-learning de calidad.
Profesorado.
Las tutorías realizadas en un máximo de 24 horas, la accesibilidad del profesor mediante chat,
videoconferencia o email, el seguimiento que profesores y tutores realizan a los alumnos evitando
el abandono, la motivación a través de chats, etc, son fundamentales para lograr la implicación del
alumnado y el cumplimiento de los objetivos de la formación.
Administración.
Importación/Exportación de datos, registro automatizado de alumnos (fundamental en los MOOC).

Integración con el ERP de la organización (RR.HH., contabilidad, etc), gestión de las copias de
seguridad, herramientas de exportación e importación gestionadas por los propios docentes,
informes de control y evaluación de los alumnos que permitan realizar el correcto seguimiento,
definición de roles (alumno, profesor, invitado, coordinador, gerente, etc) que permita una correcta
gestión de los indicadores de la organización.
Javier Pérez Bou
Comunicación.
La cantidad y calidad de las comunicaciones síncronas, los horarios, la posibilidad de visualizarlas

en diferido, la posibilidad de mostrar subtítulos a las locuciones. Gestión correcta de los email y
avisos remitidos desde la organización a los alumnos evitando que sean considerados spam.
Avisos de fechas de entrega, exámenes, hitos en la formación, etc.
Elementos de evaluación.
Cantidad y calidad de las autoevaluaciones, claridad en los métodos de evaluar al alumno desde el
primer día. La aplicación de múltiples criterios (corrección por pares, autoevaluaciones, trabajos,
etc). Información clara de fechas, resultados obtenidos, formas de recuperación, etc. Situación del
avance del alumno visualizable tanto por el alumno como por el docente.
Soporte.
Facilidad en la resolución de problemas a través de call center, servicios virtuales, email.

Disponibilidad 24x365.
Estos servicios, entre otros, complementan a la plataforma y a los contenidos pudiendo tener un
efecto muy diferenciador entre diversas organizaciones. Observamos que la separación entre
contenidos y servicios se ha difuminado quedando englobados contenidos y servicios en un mismo
paradigma en el momento de realizar el diseño y desarrollo de la formación.
4. Implantación
Vamos a diferenciar el proceso de implantar un sistema de e-learning en la organización, de la

implantación de un proyecto formativo específico en un sistema ya existente. La implantación de un
sistema supone realizar un análisis similar a cualquier otro sistema informático. Cómo mínimo
tendremos que realizar un capacity plan realizando una previsión sobre número de alumnos,
número de cursos, requerimientos de espacio en disco, de tráfico de red, etc.
Hay que tener en cuenta que el aumento de dispositivos móviles junto con cambios en las
metodologías ha provocado un uso intensivo de los recursos de vídeo en los sistemas de
e-learning. Estos recursos deben ser correctamente analizados y vigilados puesto que pueden
crecer de manera exponencial y colapsar el sistema.
Una decisión importante es si la organización va a disponer de la infraestructura o va a contratarla

vía SaaS (“Software as a Service”). Esto puede decantarnos a ir a un proveedor que nos oferta
tanto la infraestructura tecnológica como el software como pueda ser Blackboard
(www.blakboard.com), contratar un servicio de Hosting con algún proveedor e instalar nuestro
software, contratar con un proveedor que nos oferte directamente la plataforma o disponer
nosotros de nuestra propia infraestructura.
Aparte de la plataforma, hay software de terceros que probablemente tendremos que utilizar. Por
ejemplo, necesitaremos disponer de la posibilidad de realizar sesiones síncronas y/o webcasting.
En el caso de sesiones síncronas, hay dos productos de pago que lideran el mercado: Blackboard
Collaborate y Adobe Connect. Además, tiene una fuerte presencia Cisco WebEx para la realización
de webcasting. Como opción open source, disponemos de OpenMeetings entre otros, que también
permite una fácil integración con Moodle. El mercado está ampliando también las prestaciones de
productos ya existentes como es el caso de youtube, que permite realizar emisiones en streaming
de manera muy sencilla. Igualmente, google hangouts está evolucionando y quizá suponga la
alternativa de google a Connect y WebEx.
El líder claro en el mercado de plataformas e-learning es Moodle. Esto no significa que su

liderazgo vaya a ser permanente, pero es una plataforma que dispone de una gran comunidad de
usuarios y desarrolladores que permanentemente incorporan mejoras. Por otra parte, al ser una
referencia, la mayoría de fabricantes que desarrollan herramientas para e-learning generan plugins
que permiten una fácil integración con Moodle.
En la tabla siguiente podemos ver el liderazgo de Moodle en las Universidades Españolas:
Tabla XIII. Universidades Españolas y Entornos Virtuales de Aprendizaje.

Fuente: (20). Elaboración propia
PLATAFORMAS Nº de UNIVERSIDADES %
Moodle 39 48%
ESPECIFICO 18 22%
WEBCT/BlackBOARD 17 21%
SAKAI 3 4%
.LRN 2 2%
Claraonline 1 1%
Illias 1 1%
Dokeos 1 1%
Adicionalmente existen diversas plataformas para gestionar y almacenar los vídeos. Además de los
canales en Youtube, Vimeo, etc, existen en el mercado herramientas como Kaltura
(https://es.corp.kaltura.com/) u Opencast Matterhorn (http://www.opencast.org/) que incluyen
potentes visores en los que el alumno tiene grandes posibilidades de configurar la manera en que
recibe la formación a través de los vídeos. Estos productos son capaces de pasar el OCR (“Optical
Character Recognition”) a los vídeos e incluso hacer un reconocimiento de voz permitiendo indexar
los contenidos y realizar metabúsquedas en los vídeos.
Javier Pérez Bou
Para los Mooc también debe plantearse la posibilidad de utilizar alguno de los consorcios
existentes como alternativa a crear una infraestructura. Podemos destacar como plataformas más
potentes:
• Coursera (https://es.coursera.org/). Nacida en octubre de 2011 y desarrollada por

académicos de la Universidad de Stanford.
• EdX (https://www.edx.org/). Creada en Mayo de 2012 por el MIT y la Universidad de

Harvard.
• Udacity (https://www.udacity.com). Creada en el 2013 como iniciativa privada por

académicos de la Universidad de Stanford.
• MiriadaX (https://miriadax.net). Nacida a principios del 2013 a través de Universia junto

con el Banco Santander y Telefónica.
La gran ventaja de utilizar estas plataformas es la total despreocupación por la infraestructura

tecnológica y por la administración de los cursos, centrando los esfuerzos en realizar cursos de
calidad.
En cuanto a la implantación de proyectos de formación, la FAO, en su publicación “Una guía para

el diseño y desarrollo de cursos de aprendizaje empleando tecnologías de la información y las
comunicaciones” (19) establece un modelo pedagógico para definir las actividades de un proyecto
de e-learning.
Figura 1. Modelo ADDIE. Fuente (19). Elaboración propia
Análisis.
Se realizará un análisis de las necesidades con el fin de determinar si el objetivo de la formación

es proporcionar unas competencias determinadas al alumnado y si el e-learning supone una
solución adecuada para proporcionar esas competencias.
Resulta fundamental analizar el alumnado: Conocimientos previos (incluida destreza informática),

acceso a Internet, husos horarios en el caso de que existan actividades síncronas.
Identificar las labores y habilidades que los alumnos deben aprender o mejorar en su desempeño.
Fruto de este trabajo debemos ser capaces de describir el problema, la solución propuesta, el perfil
del alumno y las restricciones existentes a la hora de acceder a los recursos.
Diseño.
En primer lugar, debemos definir el conjunto de objetivos de aprendizaje necesarios para lograr el
objetivo principal del curso.
Debemos establecer el orden (secuencia) en el que los objetivos deben ser alcanzados.
Hay que seleccionar las estrategias pedagógicas que vamos a utilizar en los recursos, en el modo
de entregar los contenidos y en la evaluación.
En este punto quedará definida la estructura organizativa del curso (por ejemplo unidades,
lecciones, módulos, actividades, etc.), los objetivos asociados a cada unidad y los formatos
pedagógicos que se van a utilizar (sesiones síncronas, recursos multimedia, etc.).
Desarrollo.
Aquí es donde se hace la producción del material. Los materiales pueden ser desde pdf
debidamente estructurados, vídeos, definición de tareas, autoevaluaciones, cuestionarios,
contenido interactivo multimedia realizado con herramientas de autor, etc.
Implementación.
Es la fase de impartición. Los recursos deben de estar instalados en el servidor y puestos a

disposición de los alumnos que previamente han sido matriculados. Estos cursos ya son
administrados, supervisados y tutorizados por los responsables, evaluando las actividades y
fomentando la participación. Recordemos que una de las ventajas del e-learning es la reutilización.
Unos mismos recursos pueden ser aprovechados en varias ediciones de una manera sencilla. No
obstante, la labor de tutores y administradores tendrá que realizarse en cada edición.
Evaluación.
Todo proyecto formativo debe ser evaluado para ver el grado de consecución de los objetivos
perseguidos. Igualmente, el feedback del alumnado supone una facilidad para mejorar el curso
para siguientes ediciones.
Javier Pérez Bou
Todo proyecto e-learning requiere de un equipo de personas con capacidades específicas en cada
una de las actividades o fases del proyecto. Dependiendo de factores como el tamaño del
proyecto, las capacidades de las personas que forman parte del equipo y los medios o tecnologías
que son utilizados varios de los roles que a continuación se describen pueden ser combinados en
un único perfil:
• Director del proyecto. Realiza el análisis de necesidades y destinatarios. Coordina todas

las actividades y roles. Evalúa los resultados.
• Diseñadores Instruccionales (DI). Son los responsables de la estrategia pedagógica en

general.
• Expertos Temáticos (ET). Aportan el conocimiento y la información. Pueden ser tanto los
encargados de desarrollar los contenidos como los docentes que apoyan las actividades en
el aula.
• Desarrolladores Web y editores multimedia. Son los que organizan los elementos del
curso, crean componentes interactivos y multimedia y adaptan la interfaz de la plataforma
de enseñanza.
• Administradores de cursos, facilitadores en línea y tutores. Los administradores gestionan

las matriculaciones. Los tutores y facilitadores apoyan las actividades de los alumnos y los
motivan durante el curso. Aseguran el correcto flujo de información entre los diferentes
actores, motivan la participación y actúan de mediadores facilitando la interacción entre los
participantes.
• Expertos en apoyo técnico. En cada una de las fases del proyecto existen expertos para la
resolución de problemas.
5. Normalización
Para llevar a cabo el e-learning se hace uso de plataformas y software que posibilitan la interacción
entre profesores y alumnos.
Debido a la gran variedad de plataformas tecnológicas dedicadas a la educación y a que se precisa

la reutilización de elementos educativos, es preciso establecer una serie de normas que posibiliten
el uso y la reutilización, teniendo en cuenta la interoperabilidad y usabilidad de dichos recursos
educativos.
Estas normas y estándares deben regular el funcionamiento de los distintos componentes

relacionados con las diversas plataformas educativas. La aceptación de dichos estándares se
encuentra actualmente en un proceso de aceptación y maduración, con el objetivo de lograr la
integración e interoperabilidad entre contenidos de cursos y diversas plataformas tecnológicas.
Además, debe tenerse en cuenta la diversidad no sólo de plataformas tecnológicas, sino también
de dispositivos con los que se accede a la formación, desde dispositivos fijos a móviles, ya sean
tabletas, portátiles o smartphones. De ahí la necesidad imperiosa de estandarización.
Dicha estandarización para los cursos y los sistemas que proporcionan esa formación persigue dos
objetivos fundamentales:
• Conseguir que un curso, independientemente del LMS con el que se ha producido, pueda
ser cargado en cualquier otro LMS.
• Posibilitar el registro por el LMS de los resultados de la actividad de todos los usuarios del
curso.
La importancia de los estándares en e-learning se encuentra en lograr:
• Interoperabilidad, posibilitando el intercambio y la mezcla transparente de los contenidos

de diversas fuentes de distintos sistemas.
• Reusabilidad, garantizándose la agrupación y reutilización de forma sencilla
• Accesibilidad, de forma que un usuario pueda acceder al contenido anywhere y anytime, es

decir, dónde y cuándo el usuario lo desee.
• Durabilidad, de forma que no haya que realizar una inversión para conseguir el objetivo de
reutilización de contenidos.
• Escalabilidad, posibilitando aumentar la funcionalidad conforme lo hace la nueva

tecnología, es decir, si se incrementa la posibilidad de aumentar capacidad del sistema, el
permitirlo no supone un problema.
Según Pedruelo (21), el incremento de plataformas de formación en e-learning contrasta con los
principios básicos de productividad de los mismos. De ahí destaca la necesidad de aparición de
estándares que permitan la eficiencia y calidad en las organizaciones.
La International Organization for Standarization (ISO), define la estandarización como “la actividad
que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a
usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto
dado, que puede ser tecnológico, político o económico”.
Con la aparición de los primeros estándares en el año 2001, se garantizaba la independencia de

los contenidos y los LMS, de forma que se cumplan ciertas especificaciones sobre las que basar el
desarrollo de herramientas y contenidos (22).
La estandarización ofrece muchas ventajas al e-learning:
Javier Pérez Bou
• Garantiza la viabilidad futura de su inversión, impidiendo que sea cautivo de una única
tecnología. De modo que en caso de cambiar de LMS la inversión realizada en cursos no
se pierda.
• Aumenta la oferta de cursos disponible en el mercado, reduciendo de este modo los costes
de adquisición y evitando costosos desarrollos a medida en muchos casos.
• Posibilita el intercambio y compraventa de cursos, permitiendo incluso que las

organizaciones obtengan rendimientos extraordinarios sobre sus inversiones.
• Facilita la aparición de herramientas estándar para la creación de contenidos, de modo que

las propias organizaciones puedan desarrollar sus contenidos sin recurrir a especialistas
en e-learning.
5.1. Principales estándares
Actualmente hay diversos estándares utilizables, como son:
1. El AICC (Aviation Industry Computer-Based Training Committee), es un estándar creado

por la asociación aérea de los EEUU, para el desarrollo, la entrega, y la evaluación del
CBT (Computed Based-Training), así como de tecnologías de capacitación relacionadas.
Las especificaciones del AICC cubren nueve áreas principales, que van desde los Learning
Objects (LO) hasta los Learning Management Systems (LMS). Cuando una compañía
cumple las especificaciones de la AICC, quiere decir que cumple con al menos una de
estas guidelines y recomendaciones (AICC Guidelines and Recommendations, AGRs):
AGR 001: AICC Publications.
AGR 002: Courseware Delivery Stations.
AGR 003: Digital Audio.
AGR 004: Operating/Windowing System.
AGR 005: CBT Peripheral Devices.
AGR 006: Computer-Managed Instruction.
AGR 007: Courseware Interchange.
AGR 008: Digital Video.
AGR 009: Icon Standards: User Interface.
AGR 010: Web-Based Computer-Managed Instruction.
Si bien la AICC ha publicado varias guías, la más seguida es la que habla de la

interoperabilidad de las plataformas de formación y los cursos y esa es la AGR010, que se
ha convertido en el estándar de facto en e-learning. En esta guía se resuelven dos de los
problemas fundamentales:
Al definir un curso independientemente de la plataforma, y mediante un sistema de

descripción del curso inteligible por cualquier plataforma, la carga de cursos creados
en un LMS es independiente del mismo.
La comunicación entre el LMS y el curso, se realiza de forma que el curso puede

obtener información necesaria sobre el usuario, pudiendo realizarse un análisis y
tratamiento estadístico.
2. El IMS (Instruction Management Systems), consorcio, formado más de 190 organizaciones,

que agrupa a vendedores, productores, implementadores y consumidores de e–learning.
Su objetivo es fomentar a nivel global el crecimiento y el impacto de las tecnologías del
aprendizaje en los ámbitos educativos y de formación.
Para ello definió un tipo de fichero XML para la descripción de los contenidos de los cursos,
de modo que cualquier LMS pueda, leyendo su fichero de configuración
IMSMANIFEST.XML, cargar el curso. A continuación, se describen las principales
iniciativas de este comité:
a) Learning Object Metadata (LOM).
Esta especificación muestra cómo los contenidos deben ser identificados o

“etiquetados”, así como la organización de la información de los alumnos, de manera
de que se puedan intercambiar entre los distintos servicios involucrados en un sistema
de gestión de aprendizaje (LMS).
b) Empaquetamiento de Contenidos (Content Packaging).
Esta especificación provee la funcionalidad para describir y empaquetar material de

aprendizaje en paquetes portables e interoperables. El empaquetamiento de
contenidos está vinculado a la descripción, estructura, y ubicación de los materiales de
aprendizaje on-line, y a la definición de algunos tipos particulares de contenidos.
c) Interoperabilidad de Preguntas y Tests (Question and Test Interoperability, QTI).
Esta especificación posibilita el intercambio de tests y datos de evaluación entre

distintos LMS, mediante una estructura de datos XML.
d) Empaquetamiento de Información del Alumno (Learner Information Packaging. LIP).
Javier Pérez Bou
Define estructuras XML para el intercambio de datos de alumnos entre sistemas de

gestión de aprendizaje, sistemas de recursos humanos, sistemas de gestión del
conocimiento, y cualquier otro sistema utilizado en el proceso de aprendizaje.
e) Secuencia Simple (Simple Sequencing).
En esta especificación se definen las reglas que describen el flujo de instrucciones a

través del contenido según el resultado de las interacciones de un alumno con el
contenido. La representación de la secuencia de dicho flujo se puede intercambiar
entre distintos sistemas.
f) Diseño del Aprendizaje (Learning Design).
En este se estudian las diversas maneras de describir y codificar las metodologías de

aprendizaje.
g) Definición de competencias (Competency Definitions).
En este se describen, referencian e intercambian definiciones de competencias.

Entendiendo por tales las habilidades, el conocimiento, las tareas, y los resultados del
aprendizaje.
h) Accesibilidad (Accesibility).
Se promueve el contenido accesible a través de recomendaciones, guidelines, y

mediante modificaciones de otras especificaciones.
3. El IEEE (Institute of Electrical and Electronics Engineers), asociación de ingenieros que

desarrolla estándares internacionales para sistemas eléctricos, electrónicos,
computacionales y comunicacionales. El IEEE está organizado en distintos comités que se
reúnen y analizan las distintas tecnologías, entregando como resultado una especificación
o recomendación en forma de estándar. Uno de estos comités es el Learning Technology
Standards Committee (LTSC) o Comité para los Estándares de la Tecnología del
Aprendizaje. Lo que hizo fue recoger el trabajo del comité de la AICC y mejorarlo, creando
la noción de meta data (Norma 1484.12.1-2002).
4. El ISO (International Organization for Standardization), es una organización con el objetivo

de la creación de estándares internacionales compuesto por diversas organizaciones
nacionales de estandarización, que promueve el uso de estándares propietarios,
industriales y comerciales a nivel mundial. Tenemos, entre otras la ISO/IEC 24751:2008,
Information technology – Individualized adaptability and accessibility in e-learning,
education and training y la ISO/IEC 19796-1:2005, Information technology – Learning,
education and training – Quality management, assurance and metrics. Adicionalmente
existen multitud de normas acerca de empaquetados de contenidos, entornos
colaborativos, etc.
5. La EFQM es la European Foundation for Quality Management, y tiene como objetivo

incremento de la eficacia y la eficiencia de las organizaciones europeas. No es específico
para e-learning pero cada vez es más utilizado por las organizaciones el Modelo de
Excelencia para la mejora de la calidad de la gestión.
6. El CEN, es el Comité Europeo de Normalización, organización regional europea de

estandarización, cuyo principal objetivo es fomentar la economía europea en el negocio
global, el bienestar de ciudadanos europeos y el medio ambiente. El Simple Publishing
Interface for Learning Object Repositories (SPI), pretende crear una interfaz sencilla que
permita a los desarrolladores de objetos de aprendizaje publicar fácilmente los mismos
encapsulándolos en repositorios, facilitando la labor de los desarrolladores y favoreciendo
el acceso al usuario final.
7. La especificación CORDRA, cuyo objetivo es identificar y especificar las tecnologías

e-learning existentes apropiadas que permitan la administración y entrega de contenidos,
así como las normas de interoperabilidad que permitan su búsqueda y reutilización, para
establecer un modelo de referencia que permita el intercambio de contenidos.
8. El AENOR, es la Asociación Española de Normalización y Certificación, reconocida en

España como un organismo de normalización que actúa como entidad de certificación
según el Real Decreto 2200/1995. Su norma UNE 66181:2008 es un estándar sobre
calidad de la formación virtual
9. La ADL (Advanced Distributed Learning), es una iniciativa del Departamento de Defensa y

de la Oficina del Subsecretario de Defensa para Personal y Preparación de los EEUU, que
surgió en aras de implementar y desarrollar herramientas y tecnologías de aprendizaje,
potenciando el uso de las tecnologías de la información. Como consecuencia de ello se
impulsó el estándar bajo la denominación Shareable Content Object Reference Model,
conocido como SCORM, que es el más utilizado en e-Learning.
Los autores (23) se encargaron de observar y recopilar todos los movimientos que se producen
alrededor de la normalización en la comunidad e-learning. En el estudio se obtuvieron doce
categorías diferentes y 101 estándares, normativas o recomendaciones relacionadas con el
e-Learning, elaboradas por 23 organizaciones, dentro de las cuales se encuentran las citadas
previamente.
También cabe destacar que los estándares e-learning se clasifican, en línea con la Secretaría de
Defensa de EE.UU (24). en los siguientes tipos:
• Contenidos: estructuración lógica, estructura gráfica, empaquetamiento y seguimiento de

los resultados.
• Estudiantes: almacenamiento e intercambio de información y competencias de los

estudiantes.
• Interoperabilidad: integración de componentes de los LMS y su interoperabilidad.
Javier Pérez Bou
Metadata
Empaquetamiento
Secuencia
Información del alumno
Registros del alumno
Privacidad/Seguridad
Contenido Alumno Competencias
Interoperabilidad
Protocolos
Arquitectura
APIs
Figura 2. Carácter de los estándares e-Learning. Fuente (24). Elaboración propia.
5.2. SCORM (Shareable Content Object Reference Model)
En el año 1997 El Departamento de Defensa de se formó la iniciativa ADL (Advanced Distributed

Learning) para desarrollar principios y guías de trabajo necesarias para el desarrollo y la
implementación eficiente, efectiva y en gran escala, de formación educativa sobre nuevas
tecnologías Web.
Para ello, se basó en las mejoras proporcionadas por las iniciativas IMS y AICC. De la primera
tomó el sistema de descripción de cursos en XML y de la segunda el mecanismo de intercambio de
información mediante una API, obteniendo un Modelo de Referencia para Objetos de Contenidos
Intercambiables, en inglés Shareable Content Object Reference Model (SCORM).
De esta manera, SCORM proporciona un marco de trabajo y una referencia de implementación

detallada que permite a los contenidos y a los sistemas usar SCORM para “hablar” con otros
sistemas, logrando así interoperabilidad, reusabilidad y adaptabilidad. Todo esto se muestra
mediante:
• La disponibilidad de un Sistema de Gestión de Aprendizaje o LMS basado en Web, para

lanzar diferentes contenidos que se han desarrollado por varios autores usando
herramientas de diversos vendedores.
• La disponibilidad de LMS producidos por diferentes vendedores para lanzar un mismo

contenido.
• La disponibilidad de múltiples productos o entornos LMS basados en Web, para acceder a

un repositorio común de contenidos.
Las especificaciones de SCORM están organizadas como “libros” separados. SCORM ha sido
dividido en tres libros que se detallan a continuación:
1. Scorm Overview; contiene una descripción general de la iniciativa de ADL, un análisis de

SCORM, y un resumen de las especificaciones técnicas contenidas en las siguientes
secciones.
2. Scorm Content Aggregation Model: contiene una guía para identificar y agregar recursos
dentro de un contenido de aprendizaje estructurado. Este libro describe una nomenclatura
para el contenido de aprendizaje, describe el SCORM Content Packaging
(empaquetamiento de contenidos) y hace referencia al IMS Learning Resource Meta-data
Information Model, el cual está basado en el IEEE LTSC Learning Object Metadata (LOM)
Specification, que fue el resultado de un esfuerzo en conjunto entre el IMS Global Learning
Consortium y la Alliance of Remote Instructional Authoring and Distribution Networks for
Europe (ARIADNE).
3. Scorm Run-Time Environment: incluye una guía para lanzar contenidos y hacerle un
seguimiento en un ambiente basado en Web. Este libro es derivado del CMI001 Guidelines
for Interoperability de la AICC.
SCORM también divide el mundo de la tecnología e-Learning en componentes funcionales. Los

principales componentes son: Learning Management System (LMS) y Sharable Content Objects
(SCOs).
Figura 3. Arquitectura SCORM. Fuente (24). Elaboración propia
Javier Pérez Bou
El funcionamiento del SCORM es como el que sigue:
1. Los SCOs son los recursos de contenidos de aprendizaje y se crean de forma

independiente.
2. Estos SCOs se ensamblan en un paquete de contenido, junto a unas instrucciones de

ejecución.
3. El LMS se encuentra en el servidor y se encarga de cargar y ejecutar el paquete de

contenidos ensamblado previamente de acuerdo a las instrucciones de ejecución que se
han incorporado.
4. El LMS entrega el paquete al estudiante en su ordenador personal (PC), quien interactúa

con el contenido, enviando al LMS información de acuerdo a las instrucciones recibidas.
(1) Clark, R. C., & Mayer, R. E. (2011). E-learning and the science of instruction : Proven guidelines
for consumers and designers of multimedia learning (3rd edition). Pfeiffer.
(2) Montesinos Sanchís, P. (2014). MODELO INTEGRAL PARA LA ORGANIZACIÓN Y GESTIÓN

DE LA FORMACIÓN PERMANENTE UNIVERSITARIA A DISTANCIA BASADA EN EL
APRENDIZAJE SITUACIONAL. Doctoral dissertation.
(3) García Aretio, L. (1999). Historia de la educación a distancia. Revista Iberoamericana De

Educación a Distancia (RIED), 2(1), 11-40.
(4) UNESCO. (1998). Informe mundial sobre la educación 1998: Los docentes y la enseñanza en
un mundo en mutación. Madrid: UNESCO.
(5) Lupion Torres, P., & Rama, C. (2010). La Educación Superior a Distancia en América Latina y el
Caribe. Unisul.
(6) Garrison, D. R. (2011). E-learning in the 21st century: A framework for research and practice.
Taylor & Francis
(7) TalentLMS. (21 de septiembre de 2016). Origin Learning. Obtenido de

https://www.talentlms.com/blog/20-facts-elearning-infographic/
(8) García Marcos, C., & Cabero, J. (2016). Evolución y estado actual del e-learning en la
Formación Profesional española. Revista Iboeroamericana de Educación a Distancia.
RIED, 19(2), 167-191.
(9) Cabero, J., & Gisbert, M. (2005). La formación en internet: Guía para el diseño de materiales
didácticos. MAD-Eduforma.
(10) García Aretio, L. (2014). Bases, mediaciones y futuro de la educación a distancia en la

sociedad digital. SINTESIS.
(11) García P., F. (2005). Estado actual de los sistemas e-learning. Teoría de la Educación.
Educación y Cultura en la Sociedad de la Información, 6(2). Recuperado el 21 de 09 de
2016, de
http://campus.usal.es/~teoriaeducacion/rev_numero_06_2/n6_02_art_garcia_penalvo.htm
(12) Area, M., & Adell, J. (2009). e-Learning: Enseñar y Aprender en Espacios Virtuales. En J. De
Pablos, Tecnología educativala formación del profesorado de la era de internet (págs. 393-
424). Málaga: Aljibe.
(13) Lewin, T. (19 de 11 de 2012). College of Future Could Be Come One, Come All. New York
Times. Recuperado el 14 de 10 de 2016, de http://massiveopenonlinecourses-
repository.yolasite.com/resources/12_11-19-12-Tamar%20Lewin-
College%20of%20Future%20Could%20Be%20Come%20One,%20Come%20All-NYT.pdf
(14) Lozano Galera, J. (2004). El triángulo del elearning. Recuperado el 12 de 10 de 2016, de

http://www.telecentros.info: http://www.telecentros.info/articulosd.asp?id=35
(15) Boneu, J. (2007). Plataformas abiertas de e-learning para el soporte de contenidos educativos
abiertos. Contenidos educativos en abierto. Revista de Universidad y Sociedad del
Conocimiento (RUSC), 4(1), 36-47.
(16) Choudhury, H., & Khataniar, G. (2016). Choudhury, H., & Khataniar, G. Features Based
Comparison and Evaluation of E-learning Platform in Academic Environment. IJDACR
ISSN: 2319, 4. Recuperado el 05 de 10 de 2016, de
http://ijdacr.com/uploads/papers/40600-16-100.pdf
(17) Bolivar, J. (1 de 3 de 2011). 10 Rasgos del Aprendizaje 2.0. Recuperado el 2016, de Óptima
Infinito: http://www.optimainfinito.com/2011/03/10-rasgos-del-aprendizaje-20.html
(18) EHLERS, U. (2009). Web 2.0 – e-learning 2.0 – quality 2.0? Quality for new learning cultures.
En A. Inglis, Quality Assurance in Education (págs. 296-314).
(19) Ghirardini, B. (2014). Food and Agriculture Organization of the United Nations (FAO).
(20) Prendes, M. P. (2009). Plataformas de campus virtual de software libre: Análisis comparativo
de la situación actual en las universidades españolas. Informe del Proyecto EA-2008-0257
Javier Pérez Bou
de la Secretaría de estado de Universidades e Investigación. Recuperado el 13 de 10 de

2016, de http://www.um.es/campusvirtuales/informe.html
(21) Pedruelo, M. R. (2004). El estándar SCORM para EaD. Universidad Nacional de Educación a
Distancia, Proyecto Fin de Carrera, Tesina del Máster en Ensenanza y Aprendizaje
Abiertos.
(22) Mansó Guerra, Y., & García Sánchez, A. (2013). PLATAFORMA EDUCATIVA ZERA,
ESTÁNDARES UTILIZADOS PARA LA GESTIÓN Y DISTRIBUCIÓN DE RECURSOS
EDUCATIVOS. XV Congreso Internacional de Informática en la Educación, "INFOREDU
2013".
(23) Hilera, J. R., & Hoya, R. (2010). Estándares de e-learning: Guía de consulta. Universidad de
Alcalá.
(24) Advanced Distributed Learning. ADL. (2004). SCORM Overview.
Tema 34. Los sistemas de información geográfica.
Conceptos y funcionalidad básicos. El proyecto
gvSIG. Incorporación de la componente
geográfica en los sistemas de información
Ernesto Faubel Cubells

Colegiado 0220
La información cartográfica es de gran utilidad en un elevado número de actividades

humanas que resultan esenciales para nuestro bienestar. Es muy frecuente que
cuando se intenta comenzar a aprender algo de un lugar, lo primero que se hace es
mirar un mapa.
Asimismo, es esencial para el estudio y la gestión de problemas que tienen lugar en

un espacio geográfico, para lo que solemos utilizar un modelo simplificado del mundo
real que sea manejable y fácilmente inteligible. Este modelo primero tomó la forma de
mapa en papel y posteriormente se transformó en imágenes electrónicas que se
consultan a través de una pantalla de ordenador.
Prácticamente se puede afirmar que cualquier actividad humana o fenómeno natural,

puede estudiarse mediante la cartografía adecuada. Los mapas, son necesarios en
diferentes ámbitos y se ha demostrado su enorme utilidad en la ayuda y
reconstrucción de grandes zonas devastadas por catástrofes naturales.
Por todo ello, el ser humano, desde hace siglos ha confeccionado mapas. Hoy en día
estos procesos mediante los cuales se trata de representar la realidad en un mapa, se
lleva a cabo por medio de los Sistema de Información Geográfica (SIG), con una
tendencia a ampliar y extender su uso para que pueda conocerse y gestionarse mejor
el territorio.
De acuerdo con la definición de The National Center for Geographic Information and
Analysis (NCGIA) un Sistema de Información Geográfica (SIG) es un sistema de
hardware, software y procedimientos elaborados para facilitar la obtención, gestión,
manipulación, análisis, modelado, representación y salida de datos espacialmente
referenciados, para resolver problemas complejos de planificación y gestión
Existen numerosas definiciones que recogen bajo diversos enunciados las

características básicas de los SIG, pero para aclarar conceptos, se pueden utilizar dos
definiciones mucho más “coloquiales” y que no deben tenerse en cuenta si se
pretende ser muy riguroso:
• Es una base de datos donde los registros son elementos gráficos.
• Es un sistema gráfico con Bases de datos asociadas.
En suma, los SIG son sistemas de gestión de bases de datos geográficas, que
permiten el manejo simultáneo de planos digitales y de los datos asociados a los
mismos. Constituyen una ayuda imprescindible para gestionar recursos y actividades
en los que la componente geográfica (el territorio) sea un aspecto crítico. Su utilización
permite el análisis de la localización y las relaciones espaciales entre dichos recursos
y actividades.
1. SIG. Conceptos y funcionalidad básicos
Los Sistemas de Información Geográfica (SIG, o GIS para el acrónimo en inglés) se han convertido
en los últimos años en herramientas de trabajo esenciales en el planeamiento urbano y en la
gestión del territorio. Su capacidad para modelizar, almacenar, recuperar, analizar, y representar
amplias extensiones de terreno con enormes volúmenes de datos espaciales, les han situado a la
cabeza de una gran cantidad de aplicaciones.
Los Sistemas de Información Geográfica se utilizan actualmente en ámbitos tan diversos como la
planificación de los usos del suelo, geomarketing, gestión de infraestructuras, planificación del
transporte y de las infraestructuras gestión de servicios, modelado de ecosistemas, valoración y
planificación del paisaje, análisis de impactos visuales, análisis de inmuebles y otros muchos.
Una forma más general y fácil de definir los SIG es la que considera la disposición, en capas, de
sus conjuntos de datos. "Serie de mapas de la misma porción del territorio, donde la localización
de un punto tiene las mismas coordenadas en todos los mapas incluidos en el sistema”. De esta
forma, es posible analizar sus características temáticas y espaciales para obtener un mejor
conocimiento de la zona.
Figura 1: Organización de la información espacial en capas SIG
Los Sistemas de Información Geográfica
1.1. Funcionalidad
El uso se los SIG se ha diversificado a la práctica totalidad de las actividades públicas o privadas.
Las funciones más frecuentes son:
• Consultar información: obtención de la información tabular asociada a los elementos

gráficos.
• Medir distancias o áreas.
• Editar datos espaciales: modificación de las características alfanuméricas o geométricas de

los objetos.
• Buscar espacialmente: a partir de los atributos de una tabla, mediante filtros, podemos
obtener un resultado analizable tanto desde la propia tabla, como desde el visor
cartográfico.
• Analizar espacialmente: realización de diferentes relaciones topológicas que se pueden

establecer entre los diferentes objetos que componen el sistema. Relaciones espaciales
entre los elementos, pueden ser: estar contenido en, contener, superponer, estar en el
área de influencia de, cruzar,…
• Explicar sucesos: realización de análisis complejos multivariable que pueden ayudar a

interpretar lo que ha sucedido en el pasado.
• Predecir tendencias: previsión de lo que puede suceder en el futuro mediante el análisis de

los que ha sucedido en el pasado y lo que está sucediendo en el presente.
• Planificar estrategias: realización de análisis en base a datos georreferenciados que

pueden ayudar a la planificación a medio o largo plazo en la organización.
• Presentar eficazmente las ideas: realización de planos y mapas temáticos que muestren la
información de un modo intuitivo de forma que facilite su interpretación.
• Tomar decisiones: como consecuencia de varios de los anteriores, pueden ser de gran
ayuda a la dirección de cara a tomar decisiones fundamentadas en base a un análisis
profundo de la situación.
Figura 2: Búsqueda espacial por atributo
Figura 3: Análisis espacial por relación “Estar contenido en”
1.2. Problemas que puede resolver
Las principales cuestiones que puede resolver un Sistema de Información Geográfica, ordenadas
de menor a mayor complejidad, son:
1. Localización: preguntar por las características de un lugar concreto.
2. Condición: el cumplimiento o no de unas condiciones impuestas al sistema.
3. Tendencia: comparación entre situaciones temporales o espaciales distintas de alguna

característica.
4. Rutas: cálculo de rutas óptimas entre dos o más puntos.
5. Pautas: detección de pautas espaciales.
6. Modelos: generación de modelos a partir de fenómenos o actuaciones simuladas.
1.3. Los datos en un SIG
A la hora de representar elementos del mundo real necesitamos un sistema de referencia y un

sistema de coordenadas. La información geográfica suele expresarse con coordenadas de latitud,
longitud e incluso de altura. Sin embargo, la distancia en el terreno correspondiente a un grado de
longitud no es constante y varía en función de la latitud. A efectos de paliar dichas variaciones, se
han desarrollado sistemas de proyección y de coordenadas como la Universal Transversa de
Mercator (UTM), de uso muy extendido en los SIG. A diferencia del sistema de coordenadas
geográficas, las magnitudes en el sistema UTM se expresan en metros únicamente al nivel del
mar, que es la base de la proyección del elipsoide de referencia. Se divide la Tierra en 60 husos de
6º de longitud. Cada huso se numera con un número entre el 1 y el 60 y para la Comunitat
Valenciana corresponde el huso 30N.
En cuanto al formato, podemos comenzar analizando las ventajas de utilizar una representación
digital de datos geográficos frente a la versión analógica.
Tabla I: Representación digital vs analógica de los datos geográficos
Digital Analógica
Difícil de actualizar, implica rehacer el mapa
Fácil de actualizar
completo
Transferencia sencilla y rápida Transferencia lenta
(p. ej. vía Internet) (p. ej. vía correo)
Espacio de almacenamiento relativamente Requiere espacios de almacenamiento
pequeño (dispositivos digitales) grandes (p.ej.: cartotecas tradicionales)
Fos mapas en papel se estropean con el
Fácil de mantener
tiempo
Análisis difícil e inexacto (p.ej.: medición de
Análisis automático y fácil
áreas y distancias)
Los datos SIG normalmente representan objetos del mundo real (carreteras, usos del suelo,
altitudes). Se pueden almacenar de dos formas: raster y vectorial.
Figura 4: Modelos de almacenamiento de datos SIG
Los ficheros raster o de imagen, almacenan la información en forma de matriz de celdas (o píxeles)
organizadas en filas y columnas (o una cuadrícula) en la que cada celda contiene un valor que
representa información. Como ejemplo, se puede hablar de las fotografías aéreas o de los Modelos
Digitales del Terreno (MDT). Se suelen utilizar para representar elementos continuos.
Formatos típicos de ficheros raster son: geoTIFF (.tif), Enhanced Compression Wavelet (.ecw),
mrSID (.sid), imagen raster (.img), jpg georreferenciado (.jpg) y ESRI grid.
Figura 5: Datos raster en un SIG
Los ficheros vectoriales almacenan información geométrica de los elementos gráficos, tales como
son las coordenadas de cada punto que define el elemento. Se suelen utilizar para representar
elementos discretos. Normalmente se representan elementos de tipo punto, línea y polígono.
Veamos a continuación los formatos vectoriales más típicos en el ámbito de los SIG:
• Shapefile: es el formato más extendido y popular aunque inicialmente es propiedad de

ESRI (empresa referencia en el mundo de los SIG). Se compone de varios archivos que un
cliente SIG lee como uno único. Al menos consta de tres: el.shp (almacena las entidades
geométricas), el .shx (almacena el índice de las entidades geométricas) y el.dbf (es la base
de datos, en formato dBASE). Solo puede almacenar un tipo de geometría por cada
shapefile.
• Bases de datos espaciales: pueden ser de diferentes tipos (PostgreSQL + PostGIS, Oracle
Spatial, mySQL, etc). Aporta mejoras respecto a los shapefiles como son: mejora para el
soporte para usuarios múltiples, consultas complejas ad hoc, y el rendimiento con grandes
conjuntos de datos.
• Formatos CAD: como son DXF, DWG o DGN, normalmente utilizados para importar la
geometría de los elementos, ya que no son los adecuados para almacenar la información
alfanumérica que acompaña a los elementos gráficos.
• Cobertura: formato que tiene su origen en productos de ESRI (como ARC/INFO) contiene
datos espaciales (ubicación) y de atributos (descriptivos) de las entidades geográficas. Las
coberturas utilizan un conjunto de clases de entidades para representar entidades
geográficas. Cada clase de entidad almacena un conjunto de puntos, líneas (arcs),
polígonos o anotaciones (texto). Las coberturas pueden tener una topología, que determina
las relaciones entre las entidades. Se almacenan como directorios dentro de los cuales se
incluye cada clase de entidad como conjunto de archivos.
• GML/XML: GML (Geography Markup Language) es el estándar XML del Open Geospatial
Consortium (OGC, Organismo cuyo fin es la definición de estándares abiertos e
interoperables dentro de los SIG) para representar información de elementos espaciales.
XML (eXtensible Markup Language o lenguaje de marcas extensible) es el formato de
intercambio de los metadatos.
• KML: inicialmente desarrollado para Google Earth, es estándar de la OGC, también es muy
popular y ha hecho que se haya extendido su uso. KML significa Keyhole Markup
Language, y es un lenguaje de marcado basado en XML para representar datos
geográficos en tres dimensiones.
1.3.1. Ventajas e inconvenientes de cada tipo:
A continuación se indican una serie de ventajas e inconvenientes de cada tipo de almacenamiento

o fichero.
Ventajas Raster:
• La estructura de los datos es sencilla, con una secuencia de pixels en la que cada uno
tiene uno o varios valores de intensidad de una propiedad asociados.
• Cuando hay gran cantidad de posibles valores a representar, es más conveniente.
• Determinadas operaciones espaciales como son el overlay (o superposición) se pueden

realizar de forma más eficiente.
• Más eficiente para representar elementos continuos (altitud, temperatura,…).
Inconvenientes Raster:
• Suelen ocupar más espacio de almacenamiento.
• La calidad de representación (a no ser que reduzcamos en gran medida el tamaño del pixel
y, por tanto, aumentemos el tamaño del fichero) puede ser peor, ya que tiende a mostrar
“dientes de sierra” o bordes no redondeados. Esto puede ser especialmente problemático
cuando se visualiza la información con un alto nivel de zoom.
• Las relaciones topológicas son más difíciles de gestionar.
Ventajas Vectorial:
• Estructura de información normalmente más eficiente al ocupar menos espacio de

almacenamiento.
• La calidad de representación puede ser mejor para determinado tipo de elementos. Es más
independiente del nivel de zoom que utilicemos en cada momento.
• Las relaciones topológicas entre los elementos las gestiona de forma más eficiente,
especialmente en el caso de networks o redes (ej. cálculo de rutas).
• Permite la importación de ficheros de otros programas de dibujo vectorial (CAD).
• Más eficiente para representar elementos discretos.
Inconvenientes vectorial:
• La estructura de datos suele ser más compleja que en los raster.
• La elevada variabilidad en los valores a representar puede dificultar su representación y

hacerla más ineficiente.
• Las operaciones de superposición suelen ofrecer peores resultados que en el otro caso.
1.3.2. Ejemplos de cada modelo
Dentro de cada modelo de representación/almacenamiento, podemos diferenciar varios tipos:
Raster:
• Fotografías aéreas/imágenes satélite/planos escaneados: en los tres casos, se suele

utilizar la imagen como mapa base en forma de visualización de fondo para añadir sobre
ellos otras capas de información.
• Grids o mallas de celdas: almacena valores asociados a cada celda. Se utilizan en forma
de mapas de superficie, representando datos que cambian continuamente en un entorno
(superficie). Ofrecen un método efectivo para almacenar la continuidad en forma de
superficie. Ejemplos de magnitudes que se representan de forma apropiada con este tipo
de elementos, son elevación sobre el nivel del mar, precipitaciones, temperatura, densidad
de población,…
Figura 6: Ejemplo de grid
• Modelo Digital del Terreno (MDT) es una estructura numérica de datos que representan la
distribución espacial de una variable cuantitativa y continua. Representa generalmente la
topografía del terreno mediante las alturas en cada punto (píxel) de un territorio.
Figura 7: Ejemplo de MDT
Vectoriales
• Puntos: hay entidades geográficas que como mejor pueden ser expresadas es por un único
punto de referencia, ya que lo único que nos interesa es su simple ubicación, sin
importarnos la forma del elemento representado. Transmiten la menor cantidad de
información, pero ocupan menos espacio de almacenamiento Ejemplos: ubicaciones de

pozos, papeleras, árboles, portales o puntos de interés.
• Líneas: son elementos gráficos unidimensionales o polilíneas que se usan para representar
rasgos lineales. Importa por dónde pasa, su recorrido pero no su forma en cuanto a huella
que ocupa sobre el territorio. Normalmente incorporan como propiedad intrínseca su
longitud. Ejemplos: líneas de autobús, canalizaciones, ríos, caminos, ejes de calle,
ferrocarriles, líneas topográficas,…
• Polígonos: son elementos bidimensionales que se utilizan para representar elementos

geográficos que cubren un área particular de la superficie de la tierra. Transmiten la mayor
cantidad de información en archivos con datos vectoriales y en ellos se pueden obtener el
perímetro y el área, normalmente como propiedades intrínsecas a los objetos. La
información de su forma es relevante. Ejemplos: barrios, usos del suelo, parcelas
catastrales, lagos, límites de parques naturales,…
Figura 8: Elementos vectoriales en un SIG
1.3.3. Origen de los datos SIG
Existen diferentes métodos para obtener datos geográficos, como pueden ser topografía, geodesia,
posicionamiento por satélite, fotogrametría, teledetección, LIDAR (medición mediante un haz láser)
o, escaneo de documentos en papel, entre otros. Cuando la información es levantada directamente
en campo con métodos topográficos y geodésicos, obtenemos una lista de coordenadas (x, y, z)
con la que se puede dibujar el elemento a representar. Mediante una serie de procesos
cartográficos, se pueden obtener planos o mapas topográficos o temáticos.
En la actualidad es posible cartografiar objetos sin necesidad de conocerlos físicamente, con

ayuda de técnicas como la fotogrametría y la teledetección; medir distancias, desniveles y ángulos
de manera electrónica y digital o conocer la posición de objetos y personas con la ayuda de un
sistema global de navegación por satélite (GNSS).
La fotogrametría ha sido una de las técnicas más utilizadas en levantamientos cartográficos,

debido, principalmente, a la cobertura y precisión que puede alcanzar. Típicamente se basa en la
toma de fotografías aéreas desde un avión, aunque también hay aplicaciones para fotos tomadas
desde tierra y satélite. El vuelo fotogramétrico tiene por objeto sobrevolar un territorio para tomar
una serie de fotografías, analógicas o digitales, con la finalidad de obtener imágenes fidedignas del
área de estudio y poder realizar con éstas, cartografía para diferentes fines. Previo a su uso, se
deben realizar una serie de procesos que permitan obtener imágenes que cumplan con una serie
de requisitos, tales como: datum geodésico de referencia, proyección cartográfica, resolución,
escala y exactitud, entre otras. Finalmente, se lleva a cabo la restitución, que bajo un
procedimiento analógico, analítico o digital, a partir de pares estereoscópicos (un par de imágenes
consecutivas) se determinan la posición, dimensión, vista de planta y orientación de los objetos
representados en las fotografías, así como el relieve topográfico del territorio de estudio.
En cuanto al origen de la información cartográfica, cuando hablamos de volúmenes importantes de

información, hay que hablar de la teledetección, que es una de las principales fuentes de datos
para los SIG. Dada la amplia disponibilidad de imágenes orto-rectificadas (tanto de satélite y como
aéreas), la digitalización por esta vía se está convirtiendo en la principal fuente de extracción de
datos geográficos. Esta forma de digitalización implica la búsqueda de datos geográficos
directamente en las imágenes aéreas en lugar del método tradicional de la localización de formas
geográficas sobre un tablero de digitalización.
Independientemente del proceso utilizado para la obtención de la información cartográfica, desde

la perspectiva del usuario, podemos apreciar que las fuentes de las que recabar datos SIG son
muy variadas. En primer lugar, cabría diferenciar la información procedente de fuentes externas de
la de elaboración propia. En cuanto a las fuentes externas, hay que destacar la tendencia a que las
administraciones públicas compartan su información cartográfica dentro de una política de datos
abiertos. A nivel de la Comunitat Valenciana, la fuente principal de información cartográfica es el
Institut Cartogràfic Valencià. En cuanto a la elaboración propia, los SIG incluyen funcionalidades
para la creación y edición de información cartográfica. No podemos obviar, la posibilidad de
incorporar ficheros CAD. En este caso, existe la posibilidad de crear la información directamente,
dibujándola o mediante la digitalización, donde a partir de un mapa impreso o con información
tomada en campo se transfiere a un medio digital.
2. El proyecto gvSIG
gvSIG es un proyecto de desarrollo en software libre con licencia GPL (software libre) que surge
como un cliente SIG destinado a satisfacer las necesidades de los usuarios de la Generalitat
Valenciana. Inicialmente se financió con fondos europeos.
El nombre de gvSIG corresponde al acrónimo formado a partir de Generalitat Valenciana Sistema

de Información Geográfica.
Figura 9: Logotipo del proyecto gvSIG
A finales de 2002 la Conselleria de Infraestructuras y Transporte de la Generalitat Valenciana

emprende un proceso de migración a sistemas abiertos bajo Linux de todos sus sistemas
informáticos.
Dentro de este proceso adquiere un especial relieve la migración del software de SIG y CAD, ya
que por las características de la Conselleria eran relevantes los usuarios que trabajaban, de una u
otra manera, con información cartográfica.
A esto se suma que dentro del mundo del software libre, en esos momentos, el SIG y el CAD eran
áreas prácticamente desconocidas. Se realizó un estudio de la comunidad del software Libre,
comparando los proyectos relacionados con los Sistemas de Información Geográfica con el
software propietario más extendido en el mercado y teniendo en cuenta las necesidades de una
administración con las características de la Conselleria de Infraestructuras y Transporte.
Para conocer estas necesidades se diseñó una encuesta que recogía la máxima información
posible de los usuarios que en aquel momento trabajaban con información geográfica, así como de
los posibles usuarios potenciales. La encuesta recogía información de todo tipo, desde las tareas y
funciones de cada uno de los encuestados al hardware y software que utilizaba, tanto gráfico como
no gráfico, realizando especial hincapié en las herramientas SIG / CAD utilizadas, en los formatos,
tipos de datos cartográficos, operaciones habituales, frecuencia de actualización, programación a
medida,…
Con toda la información recogida, tanto del estudio de necesidades como de software disponible
en la comunidad del software libre, se concluyó que no se encontraba lo suficientemente avanzado
ningún proyecto que permitiera la migración de software propietario a abierto en los campos de los
Sistemas de Información Geográfica y Diseño Asistido por Ordenador, pero sí que se podía
abordar la tarea de poner en marcha un proyecto de desarrollo encaminado a cubrir las carencias
existentes.
La Conselleria de Infraestructuras y Transporte sacó a concurso público el desarrollo de un SIG

que solventara las necesidades de sus usuarios y que cumpliera las siguientes características:
• Portable: funciona en distintas plataformas hardware / software, inicialmente Linux y

Windows.
• Modular: ampliable con nuevas funcionalidades una vez finalizado su desarrollo.
• De código abierto: el código fuente original con el que fue escrito y posteriores
modificaciones, está disponible.
• Sin licencias: una vez finalizado el desarrollo no hay que pagar nada por cada instalación
que se realice, sin límite de número.
• Interoperable con las soluciones ya implantadas: es capaz de acceder a los datos de otros
programas propietario sin necesidad de cambiarlos de formato.
• Sujeto a estándares: sigue las directrices marcadas por el Open Geospatial Consortium
(OGC) y la Unión Europea.
Desde el año 2010 la gestión y el mantenimiento del catálogo tecnológico gvSIG es llevado a cabo
por la Asociación gvSIG, una asociación que engloba tanto entidades empresariales como no
empresariales (universidades, administraciones públicas, institutos geográficos, institutos
tecnológicos, etc.).
Anualmente se organizan jornadas sobre el proyecto en diferentes localizaciones. Las que más
ediciones han celebrado son las que tienen lugar en Valencia. También se realizan en México,
Perú, Brasil y, con carácter itinerante, en Latinoamérica y Caribe.
Es decir, gvSIG es un software integrador, capaz de trabajar con información de cualquier tipo u
origen, tanto en formato raster como vectorial. Además, permite trabajar con formatos de otros
programas como Autocad, Microstation o ArcView, de acuerdo con los parámetros de la OGC
(Open Geospatial Consortium) que regula los estándares abiertos e interoperables de los Sistemas
de Información Geográfica. Las herramientas que implementa permiten una gran precisión en
edición cartográfica, incluye funciones avanzadas para usos en teledetección, morfometría e
hidrología, y otras funciones básicas como diseño de impresión y soporte de los formatos más
populares, tanto vectoriales como de imágenes.
Su funcionamiento es multiplataforma, lo que influye en la elección de Java como lenguaje de

desarrollo.
Son variados los productos que componen el proyecto gvSIG.
En cuanto a la plataforma sobre la que se ejecutan:
• gvSIG Desktop: versión de escritorio del programa.
• gvSIG Mobile: versión para dispositivos móviles.
Productos para sectores concretos:
• gvSIG Roads: gestión integral de infraestructuras viarias.
• gvSIG Educa: SIG aplicado a la educación primaria y secundaria.
• gvCity: gestión de inventarios, incidencias y datos abiertos.
También integra algunas herramientas de desarrollo:
• gvNIX: herramienta para el desarrollo rápido de aplicaciones web.
• I3Geo: aplicaciones para el desarrollo de mapas interactivos en web.
Vamos a describir con mayor profundidad los dos primeros:
2.1. gvSIG Desktop
Es la versión de escritorio disponible para entornos Windows (32 y 64 bits), varias distribuciones de
Linux y MacOS (únicamente en versión portable). Se trata de un SIG potente, fácil de usar,
interoperable y cuyo uso se ha extendido por numerosos países del mundo. Se puede afirmar que
es el producto estrella del proyecto
gvSIG Desktop es capaz de trabajar con una amplia variedad de formatos, vectoriales y raster,
ficheros, bases de datos y servicios remotos, ofreciendo todo tipo de herramientas para analizar y
gestionar información geográfica. Está diseñado para ser fácilmente extensible, permitiendo una
mejora continua de la aplicación y el desarrollo de soluciones a medida.
La información se estructura y organiza por proyectos. Cada proyecto puede contener una serie de
documentos de diversos tipos:
• Vistas: donde se integran las capas de información, se aplica simbología, se realizan

consultas y análisis,… Se puede afirmar que es el documento fundamental de trabajo.
• Tablas: permiten la gestión de las tablas asociadas a las capas de información u otras sin
vinculación geográfica pero que pueden ser enlazadas con las anteriores.
• Mapas: documentos pensados fundamentalmente para realizar una composición en papel

para su impresión.
• Gráficos: permiten representar en forma de gráficos de diferentes tipos (tarta, barras,

puntos,…) la información contenida en tablas.
Figura 10: Ventana de proyecto de gvSIG
2.2. gvSIG Mobile
gvSIG Mobile es un SIG orientado a dispositivos móviles, ideal para proyectos de captura y
actualización de datos en campo.
Se caracteriza por disponer de una interfaz amigable, siendo capaz de acceder a los formatos más
comunes. Cuenta con un amplio número de herramientas SIG y GPS ideales para trabajar con
información de naturaleza geográfica.
Tiene como objetivo ampliar las plataformas de ejecución de gvSIG Desktop a una gama de
dispositivos móviles, para dar respuesta a las necesidades de un creciente número de usuarios de
soluciones móviles que desean hacer uso de un SIG en diferentes tipos de dispositivos.
Se puede considerar tanto un Sistema de Información Geográfica como un cliente de

Infraestructuras de Datos Espaciales para dispositivos móviles. Es, además, el primer cliente de
estas características licenciado como software libre.
3. Incorporación de la componente geográfica en los

sistemas de información
La mayor parte de la información que gestiona una organización, ya sea de carácter público o
privado, es susceptible de ser georreferenciada, es decir, se puede ubicar en una posición
geográfica sobre una base cartográfica, ya sea a partir de sus coordenadas, su dirección postal, un
cruce de dos o más vías o la división administrativa a la que pertenece.
Está demostrado que el cerebro humano procesa de manera mucho más rápida y eficaz las
imágenes que la información alfanumérica. Por eso es mucho más eficaz ver un mapa, en papel o
en una pantalla, que leer un escrito que contenga toda la información cartografiada, o que una
tabla con los valores de las variables que definan el territorio.
Al incorporar el componente geográfico, facilitamos la interpretación de la información y ampliamos

la capacidad de manejar y entender grandes volúmenes de información, teniendo a los visores SIG
como integradores de la misma y pudiendo servir como sistema de apoyo a la toma de decisiones
para la dirección de las organizaciones en las que se utilizan.
Existen diferentes formas de asociar información geográfica a elementos que inicialmente no la

tienen. Uno de esos procedimientos se denomina técnicamente Geocodificación. Es el proceso de
asignar una posición geográfica (coordenadas) a objetos que previamente no la tenían, a través de
su dirección. Las coordenadas geográficas producidas pueden luego ser usadas para localizar el
punto del mapa en un Sistema de Información Geográfica.
Otra forma de añadir el componente geográfico a elementos alfanuméricos consiste en la unión o

enlace de 2 tablas: una que será la correspondiente a la que contiene los elementos geográficos
(ej. Shapefile) sobre los que se quiere mostrar esa información, y otra con los registros a los que
les queremos dar una representación geográfica. Como ejemplo, podríamos de0scribir el caso de
una capa de información geográfica con los barrios de una ciudad sobre la que queremos mostrar
unos datos estadísticos contenidos en una tabla/hoja de cálculo y obtener un plano temático
Figura 11: Unión de tabla a un shapefile para obtener temático
4. Conclusiones/Resumen
Los Sistemas de Información Geográfica han extendido en gran medida su ámbito de aplicación Su
utilidad es enorme tanto en la esfera pública como en la privada. Se trata de sistemas que
combinan la información gráfica, en forma de mapas con información alfanumérica en forma de
tablas. Con ello podemos realizar operaciones como búsquedas o análisis espaciales que sin los
SIG serían muy complejos de realizar. La información se suele estructurar en capas que
representan diferentes objetos sobre un determinado espacio geográfico.
Un elemento fundamental de los SIG son los datos. Existen diferentes procedimientos de obtención
y se clasifican, a grandes rasgos, en raster y vectoriales. Entre los raster, tenemos las fotografías
aéreas o las grid, mientras que los datos vectoriales suelen representar elementos mediante
puntos, líneas o polígonos.
En cuanto a gvSIG, se trata de un proyecto de software libre impulsado por la Generalitat

Valenciana y que ha tenido una destacable expansión por todo el mundo. Permite integrar y
gestionar datos en diversos formatos y ofrece funcionalidad comparable con los productos más
extendidos y con mayor reputación en el mercado.
Finalmente, hay que destacar el hecho de que un porcentaje muy alto de la información que
maneja una organización es susceptible de ser georreferenciada. Con la conversión/adaptación de
datos inicialmente sin componente geográfica para que la incluyan, se amplían las posibilidades en
el tratamiento de la información y se facilita su incorporación a los sistemas de apoyo a la toma de
decisiones
(1) Bosque Sendra, J. , García, R. (2000). El uso de los Sistemas de Información Geográfica en la
Planificación territorial. Madrid. Anales de Geografía de la Universidad complutense
(2) Bernabé-Poveda, M.; López-Vázquez C. (2012) Fundamentos de las Infraestructuras de Datos

Espaciales (IDE) Ed. UPM-Press.
(3) Asociación gvSIG (2016) Manual de gvSIG. Valencia. Conselleria de Infraestructuras y

Transportes
(4) Alonso-Sarria, F. (2013) Temario de Sistemas de Información Geográfica. Universidad de

Murcia.
(5) Robinson, A., Sale, R. Morrison, J. L. y Muehrcke, P. C. (1987). Elementos de cartografía.

Omega.
(6) Caso-Osorio E. (2010) Manual de ArcGIS 9.3 Básico. Huancayo
(7) Santos Preciado, J. (2002). El tratamiento informático de la información geográfica.:Ed. UNED
http://mappinggis.com/ Formación SIG difusión tecnológica
https://langleruben.wordpress.com/
http://www.esri.com
https://commons.wikimedia.org
https://es.wikipedia.org
http://www.gvsig.com/
Tema 35. Infraestructuras de datos espaciales.
Definición y componentes. Legislaciones vigentes
(INSPIRE y LISIGE). Arquitectura de una IDE.
Servicios web de una IDE: mapas, catálogo,
objetos geográficos, geoprocesamiento y
observación de sensores. Aplicaciones
geoespaciales

Colegiado 0220
La cooperación entre las Administraciones Públicas es esencial para proporcionar los

servicios a los ciudadanos y garantizarles su derecho a relacionarse con ellas por
medios electrónicos. Dicha cooperación requiere unas condiciones tales que permitan
que la misma se pueda llevar a cabo con fluidez para lo cual es necesario que haya
interoperabilidad.
El Esquema Nacional de Interoperabilidad, (ENI), regulado por el Real Decreto 4/2010,

de 8 de enero, establece el conjunto de criterios y recomendaciones que deberán ser
tenidos en cuenta por las AA.PP. para la toma de decisiones tecnológicas que
garanticen la interoperabilidad. Los objetivos fundamentales del ENI son los
siguientes:
• Comprender los criterios y recomendaciones que deberán ser tenidos en

cuenta por las AA.PP. para la toma de decisiones tecnológicas que garanticen
la interoperabilidad que permita el ejercicio de derechos y el cumplimiento de
deberes a través del acceso electrónico a los servicios públicos, a la vez que
redunda en beneficio de la eficacia y la eficiencia, y que eviten la
discriminación a los ciudadanos por razón de su elección tecnológica.
• Introducir los elementos comunes que han de guiar la actuación de las AA.PP.
en materia de interoperabilidad.
• Aportar un lenguaje común para facilitar la interacción de las AA.PP., así como
la comunicación de los requisitos de interoperabilidad a la industria.
La interoperabilidad se concibe desde una perspectiva integral, de manera que no

caben actuaciones puntuales o tratamientos coyunturales, debido a que la debilidad de
un sistema la determina su punto más frágil y, a menudo, este punto es la
coordinación entre medidas individualmente adecuadas pero deficientemente

ensambladas.
Este concepto, obviamente no es ajeno a la información de carácter geográfico. La

necesidad de estructurar de una forma correcta la información con el objetivo de
compartirla, ha sido una de las causas de aparición de las conocidas como
Infraestructuras de Datos Espaciales (IDE)
Una Infraestructura de Datos Espaciales, IDE, es un conjunto de datos, metadatos,

tecnologías, políticas, estándares, recursos humanos y usuarios, armonizados e
integrados en un sistema virtual para compartir información geográfica en la red. Una
IDE se materializa a través de un Geoportal que incluye una serie de servicios que
serán descritos a lo largo del tema.
Asimismo, es necesario establecer un marco legal que asegure que los datos
producidos por las instituciones serán compartidos y que promueva su uso entre los
ciudadanos. En este ámbito, aparece la Directiva INSPIRE a nivel europeo y su
transposición al ordenamiento jurídico español, la conocida como LISIGE (Ley sobre
las Infraestructuras y los Servicios de Información Geográfica en España).
Los estándares abiertos son básicos en el entorno de las IDE para garantizar una
correcta comunicación entre clientes y servidores, y su adopción implica una larga
serie de ventajas, aumentando las posibilidades de uso de la IDE y la potencia de los
datos y herramientas que se incluyen en estas. Existen diversas organizaciones que
desarrollan estos estándares, siendo OGC e ISO las más relevantes en el campo de la
información geográfica
1. Definición y componentes
1.1. Definición
Una Infraestructura de Datos Espaciales (IDE) es un sistema informático integrado por un conjunto
de recursos (catálogos, servidores, programas, aplicaciones, páginas web,…) que permite el
acceso y la gestión de conjuntos de datos y servicios geográficos (descritos a través de sus
metadatos), disponibles en Internet, que cumple una serie normas, estándares y especificaciones
que regulan y garantizan la interoperabilidad de la información geográfica.
La puesta en práctica de un proyecto IDE se materializa a través de un Geoportal (sitio web que
contiene, al menos, un cliente que permite la utilización de servicios remotos de información
geográfica) que ofrezca como mínimo las siguientes tres funcionalidades:
• Visualización de los datos geográficos a través de servicios web y, opcionalmente, su

consulta.
• Catálogo de información geográfica que posibilite la búsqueda de conjuntos de datos y

servicios a través del contenido de sus metadatos.
• Nomenclátor que permita la localización en un mapa a través de un nombre geográfico.
1.2. Componentes
Las IDE están compuestas por una serie de elementos que podemos agrupar en
• Componentes geográficos Datos y Metadatos.
• Componentes tecnológicos: Estándares, Servicios e Infraestructura de comunicaciones.
• Componentes políticos: Políticas.
• Componentes sociales: Usuarios.
Figura 1: Componentes de una IDE
1.2.1. Datos
Antes de la aparición de las IDE, los datos geográficos se encontraban dispersos y fragmentados
en diferentes administraciones, organismos y/o empresas. Esta dispersión provocaba situaciones
problemáticas. Se duplicaban esfuerzos en la captura y mantenimiento de la información
geográfica, ya que se podían solapar las acciones de diferentes actores. Adicionalmente, era
complicado encontrar cartografía apropiada para un determinado fin, ya que había que solicitarla a
distintos organismos, cada uno con sus peculiaridades, y habitualmente la información obtenida no
era coherente.
Cuando hablamos de datos que conforman la información geográfica, podemos diferenciar:
• Datos de Referencia: son los que forman el Mapa Base o mapa sobre el que se referencian
los datos, tales como la cartografía base, fotografías aéreas, redes de transporte red
hidrológica, el relieve, los límites administrativos, etc.
• Datos Temáticos: son datos que proporcionan información sobre un fenómeno concreto:
usos del suelo, clima, fenómenos naturales, actividades económicas, educación,
vegetación, población, etc.
En relación a los datos, la Directiva INSPIRE establece que se aplicará a los conjuntos de datos
espaciales que cumplan las siguientes condiciones:
• Se refieran a una zona sobre la que un Estado miembro tenga y/o ejerza jurisdicción.
• Estén en formato electrónico.
• Obren en poder de alguna de las partes que figuran a continuación, o de una entidad que
actúe en su nombre:
Una autoridad pública, después de ser producidos o recibidos por una autoridad
pública, o sean gestionados o actualizados por dicha autoridad y estén comprendidos
en el ámbito de sus actividades públicas.
Un tercero al que se hubiera facilitado el acceso a la red con arreglo a lo dispuesto en

el artículo 12 de la Directiva.
• Traten de uno o más de los temas recogidos en los anexos I, II o III.
Figura 2: Temas de datos de los Anexos I, II y III de INSPIRE
1.2.2. Metadatos
Los Metadatos de la información geográfica son datos que describen a los datos que la conforman.
Es decir, los Metadatos de la información geográfica informan a los usuarios sobre las
características de los datos geográficos.
Los Metadatos son:
• Datos sobre otros datos.
• Datos sobre documentos, servicios, páginas web…
• Descripciones estructuradas de un objeto de información.
• Un conjunto de elementos y atributos para caracterizar la información.
• Estándares semánticos para describir objetos de datos discretos.
Pueden ser relativos a Descubrimiento o Búsqueda, Exploración o Elección, y a Explotación o

Utilización Responden a las siguientes preguntas: ¿Qué? ¿Por qué? ¿Cuándo? ¿Quién? ¿Dónde?
¿Cómo?
Los elementos que conforman el Metadato son de carácter:
• Descriptivo.
• Administrativo.
• Relativo a su Conservación y Derechos.
• Técnico y estructural.
• Relativo al uso y gestión del sistema.
Ofrecen información sobre:
• Nombre y descripción del conjunto de datos.
• El tipo de dato y, en particular, el modelo de representación empleado.
• El formato en que se almacenan los datos.
• Razones para la recogida de esos datos y de sus usos.
• La extensión geográfica de los datos.
• Calidad/precisión de los datos.
• Fecha de creación/obtención del conjunto de datos y periodicidad de su actualización.
• Responsable de la generación de los datos, del suministrador de los datos y posiblemente

de los usuarios a los que van dirigidos.
• Propietario de los datos.
• Criterios, precios (en caso de ser de pago) y limitaciones de uso.
Con toda esta información incluida en los metadatos, los usuarios pueden conocer en profundidad
los datos y puedan buscar y seleccionar los que más les interesen. Esto permite explotar los datos
de la manera más eficaz posible.
1.2.3. Estándares
La creación y adopción de estándares, entendiendo como tales especificaciones dadas por una
autoridad relativa a una materia, hace posible la interoperabilidad y que los sistemas se entienden.
Uno de los principales objetivos de las IDE, probablemente el principal, es el de compartir la

información geográfica, para consultarla o utilizarla hasta donde permita el propietario de esos
datos. Dichos estándares afectan a los protocolos de comunicación entre las máquinas que los
usen, los formatos de intercambio, las descripciones de los datos, las especificaciones de
servicios,…
Cuando hablamos de información geográfica, los principales actores que desarrollan

especificaciones y estándares en el área son:
• OGC (Open Geospatial Consortium) que desarrolla la iniciativa más importante relacionada
con la interoperabilidad a nivel de información geográfica.
• ISO (Organización Internacional de Estandarización), a través de su Comité Técnico 211

(ISO/TC211) que se encarga de estandarizar lo relacionado con la información geográfica.
• En España, el Grupo de Trabajo IDEE del Consejo Superior Geográfico.
1.2.4. Servicios
Los servicios IDE ofrecen funcionalidades accesibles vía Internet mediante un navegador u otro
tipo de aplicación geomática.
Los servicios más importantes de una IDE son los siguientes:
• Servicio de Mapas en Web o Web Map Service (WMS): permite la visualización de manera
dinámica de cartografía generada a partir de una o varias fuentes como pueden ser un
fichero de datos de un SIG, un mapa digital, una ortofoto o una imagen de satélite. Con
este servicio, los clientes no obtienen propiamente datos originales, sino una imagen digital
que permite la representación de estos mismos datos espaciales en la pantalla de su
ordenador. Se puede consultar cierta información disponible acerca del contenido de la
cartografía que se visualiza.
• El servicio WMTS, o servicio de mapas teselado, igual que el WMS, proporciona una
imagen digital a partir de datos geográficos, pero aumenta considerablemente la velocidad
de respuesta, ya que parte de colecciones de teselas o porciones de imágenes ya
pregeneradas, a unos intervalos de escala definidos.
• Servicio de Características en Web o Web Feature Service (WFS): permite acceder a los
datos en formato vectorial mediante un lenguaje específico denominado GML (Geographic
Markup Language). Se accede al archivo que define la geometría descrita por un conjunto
de coordenadas de un objeto cartográfico.
• Servicio de Coberturas en Web o Web Coverage Service (WCS): es un servicio similar a

WFS para datos en formato raster que permite consultar el valor del atributos o atributos
almacenados en cada píxel.
• Servicio de Catálogo (CSW). Permite buscar y consultar los registros de metadatos de los
conjuntos de datos y de los servicios web de la infraestructura de datos espaciales. Es
decir, da la posibilidad de buscar información de datos, servicios, aplicaciones y en general
de todo tipo de recursos. Permite la gestión de los Metadatos para llevar a cabo
búsquedas.
• Servicio de Nomenclátor (Gazetteer): Permite localizar un elemento geográfico mediante su

nombre, en base a la consulta de listas de nombres geográficos, los llamados
Nomenclátores, que vinculan coordenadas geográficas a cada nombre. Devuelve la
localización, mediante sus coordenadas, del elemento localizado.
1.2.5. Infraestructura tecnológica y de comunicaciones
Para soportar los grandes volúmenes de información que se gestionan a través de las IDE, es
necesaria una infraestructura tecnológica que subyace a todo el sistema.
No podemos obviar la gran importancia de Internet en el campo de las IDE, dado que es necesario
que existan redes accesibles para los usuarios y que estas redes soporten el tráfico producido
cuando un usuario realiza una petición a un servidor y este le responde con la información
geográfica solicitada. Es decir, Internet es el medio en el que la IDE se desarrolla es efectiva.
1.2.6. Políticas
Dado que la parte principal del trabajo de captura y mantenimiento de la información geográfica se
lleva a cabo desde el sector público, las políticas que éste determine con respecto a su
mantenimiento, recolección y uso son las que mayor impacto tienen sobre las IDE. Ello no quiere
decir que no afecte al sector privado, ya que es uno de los principales interesados en el uso de la
información proporcionada por una IDE.
1.2.7. Usuarios
Constituye uno de los principales pilares dentro de una IDE, en cuanto a consumidores de la
información geográfica compartida. Es importante conocer quiénes son los usuarios potenciales de
cada una de las IDE y las necesidades que van a tener para poder definir los roles e identificar y
evitar conflictos de interés entre usuarios.
2. Legislación vigente
Cuando hablamos de Infraestructura de Datos Espaciales a nivel de legislación, dos son los
instrumentos fundamentales: La Directiva INSPIRE a nivel europeo y su transposición al marco
legal español, la conocida como LISIGE.
La Directiva INSPIRE (Infrastructure for Spatial Information in Europe) INSPIRE 2007/2/CE, de 14

de marzo de 2007, establece las reglas generales para el establecimiento de una Infraestructura de
Información Espacial en la Unión Europea basada en las Infraestructuras de Datos Espaciales

correspondientes a la información geográfica de los Estados miembros. Es decir, establece una
Infraestructura de Datos Espaciales común.
Figura 3: Logotipo de INSPIRE
La Directiva 2007/2/CE fue desarrollada en colaboración con los Estados miembros y países que
se encontraban en proceso de adhesión con el objetivo de hacer disponible la información
geográfica relevante y de calidad, de forma que se permitiera la formulación, implementación,
monitorización y evaluación de las políticas de impacto o de dimensión territorial de la Unión
Europea.
Para asegurar que las IDE de los diferentes Estados miembros de la Unión sean compatibles e
interoperables en un contexto comunitario y transfronterizo, la Directiva exige que se adopten una
serie de Normas de Ejecución específicas para las áreas de metadatos, conjuntos de datos,
servicios de red, servicios de datos espaciales, y servicios de uso compartido y seguimiento e
informes. Este conjunto de normas se consideran Decisiones o Reglamentos de la Comisión y, por
tanto, son de obligado cumplimiento en cada uno de los países miembros de la Unión. La
implementación técnica de estas normas se realiza mediante las Guías Técnicas o Directrices,
consistentes en una serie de documentos técnicos basados en estándares y normas
internacionales.
La transposición de la Directiva INSPIRE al ordenamiento jurídico español se realiza a través de la

Ley 14/2010, de 5 de julio, sobre las Infraestructuras y los Servicios de Información Geográfica en
España (LISIGE), incluyendo el establecimiento de la Infraestructura de Información Geográfica de
España, que integra el conjunto de infraestructuras y servicios interoperables de información
geográfica bajo responsabilidad de las Administraciones Públicas españolas.
La LISIGE supone la renovación conceptual de la norma básica sobre cartografía que estaba
vigente en España hasta ese momento. Concretamente, se trataba de la Ley 7/1986, de 24 de
enero, de Ordenación de la Cartografía, que se desarrolló a nivel reglamentario mediante el Real
Decreto 1545/2007, de 23 de noviembre, que regulaba el Sistema Cartográfico Nacional.
La LISIGE se aplica a todos los datos geográficos que cumplan las siguientes condiciones:
• Se refieran a una zona geográfica del territorio nacional, el mar territorial, la zona contigua,
la plataforma continental y la zona económica exclusiva, generada o bajo responsabilidad
de las Administraciones públicas y sobre la que el Estado tenga jurisdicción.
• Estén en formato electrónico.
• Su producción y mantenimiento sea competencia de una Administración u organismo del

sector público.
• Se refieran a Información Geográfica de Referencia o a Datos Temáticos Fundamentales; o

a Datos Temáticos Generales existentes, salvaguardando en este caso los intereses
prioritarios de la defensa nacional.
Los datos geográficos y servicios proporcionados por las distintas Administraciones Públicas u
organismos del sector público integrados en la Infraestructura de Información Geográfica de
España estarán disponibles a través del Geoportal de la Infraestructura de Datos Espaciales de
España (IDEE), cuyo responsable de su mantenimiento es la Dirección General del Instituto
Geográfico Nacional.
Hay algunas otras normas del ordenamiento jurídico español que pueden tener algún punto de
posible interacción con la LISIGE:
• La Ley 37/2007, de 16 de noviembre, sobre reutilización de la información del sector

público.
• La Ley 27/2006, de 18 de julio, por la que se regulan los derechos de acceso a la

información, de participación pública y de acceso a la justicia en materia de medio
ambiente, en tanto que incorporen al derecho español la Directiva 2003/4/CE.
• La Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter

Personal, cuando la información geográfica incorpore, directa o indirectamente, datos de
este tipo.
Hay que destacar que existe un Informe sobre el alcance de la Directiva INSPIRE y su
incumplimiento. Su contenido incluye:
• El alcance de la Directiva INSPIRE, de la LISIGE y de los Reglamentos europeos que la

implementan (a qué obligan, a quiénes y en qué plazos).
• Los mecanismos coercitivos de que dispone la Unión Europea para garantizar su

cumplimiento e implementación.
• Información sobre los mecanismos y procedimiento de los que dispone el Estado español
para repercutir una penalización económica, en caso de ser impuesta a España en un
ámbito gubernamental concreto, a otro nivel de la administración, como puede ser una
comunidad autónoma, una diputación provincial o un municipio.
En cuanto a la Normativa aplicable en la Comunitat Valenciana, hay que destacar una Resolución
de 2010 por la que se dispone la publicación del convenio de colaboración entre la Administración
General del Estado, a través de la Presidencia del Consejo Superior Geográfico, y la Generalitat, a
través de la Conselleria de Medio Ambiente, Agua, Urbanismo y Vivienda, por el que la Generalitat
Valenciana se integra en el Sistema Cartográfico Nacional (SCN) y se establecen los contenidos
del Real Decreto 1545/2007 que regula el SCN.
3. Las IDE en España y la Comunitat Valenciana
La Infraestructura de Datos Espaciales de España (IDEE) desarrollada legalmente en la LISIGE,

facilita a todos los usuarios la localización, identificación, selección y acceso, a los datos y
servicios producidos en España a través de este geoportal web, cuya constitución y mantenimiento
corresponde a la Dirección General del Instituto Geográfico Nacional.
El Instituto Geográfico Nacional, a través del Centro Nacional de Información Geográfica tiene
encomendada la función de la planificación y gestión de la Infraestructura de Información
Geográfica de España, así como la armonización y normalización, en el marco del Sistema
Cartográfico Nacional, de la información geográfica oficial. Igualmente, la planificación y desarrollo
de servicios de valor añadido y de nuevos sistemas y aplicaciones en materia de información
geográfica, especialmente para el aprovechamiento en el ámbito de las Administraciones Públicas.
La IDEE Tiene como objetivo integrar a través de Internet, los datos, metadatos, servicios e
información de tipo geográfico que se producen en España, tanto a nivel estatal, como a nivel
autonómico y local, cumpliendo una serie de condiciones de interoperabilidad (normas, protocolos,
especificaciones) y conforme a sus respectivos marcos legales. Es decir, IDEE es el resultado de
la integración de:
• Todas las IDE establecidas por los productores oficiales de datos a nivel tanto estatal como
autonómico y local.
• Todo tipo de infraestructuras sectoriales y privadas.
En cada Comunidad Autónoma y cada organismo de la Administración General del Estado (AGE)
hay un representante, responsable de la implantación de la IDE en su respectivo ámbito.
Asimismo, la IDEE forma parte de la Infraestructura de Datos Espaciales Europea, desarrollada

legalmente en la Directiva INSPIRE e incorporada al ordenamiento jurídico español mediante la
LISIGE. Así pues, la IDEE es el resultado de la implementación de la Directiva INSPIRE por parte
de España.
La Infraestructura de datos espaciales de la Comunitat Valenciana (IDECV) es el conjunto de

elementos y servicios para asegurar la cooperación de entidades públicas y privadas con el
objetivo de hacer accesible la información geográfica de nuestro territorio.
El organismo responsable de la IDECV es el Institut Cartogràfic Valencià, organismo autónomo de

carácter mercantil, adscrito a la Conselleria con competencias en gestión del territorio (con
diferentes nomenclaturas a los largo de los últimos años), cuyo objetivo es impulsar, coordinar y,
en su caso, fomentar las tareas de desarrollo cartográfico, fotogramétrico, geodésico, topográfico y
de cualquier otra tecnología geográfica en el ámbito de las competencias de la Generalitat
Valenciana.
La IDECV permite:
• Acceder, de manera fácil, cómoda, eficaz, confiable y a bajo costo, a los datos geográficos
de los asociados a la IDECV.
• Reutilizar la información geográfica generada en un proyecto para otras finalidades

diferentes.
4. Arquitectura de una IDE
Una arquitectura informática es un conjunto de elementos hardware y software cuyos componentes

trabajan en conjunto, de forma que tienen la capacidad de comunicarse entre ellos a través de
servicios. Para que los elementos de una arquitectura informática puedan intercambiar operaciones
y datos, existen una serie de estándares y protocolos de comunicación que permiten la
interoperabilidad, que ya ha sido analizada anteriormente en este tema.
La creación de una IDE necesita una arquitectura informática que la soporte y que garantice las
comunicaciones entre todos los actores en la información geográfica. Las IDE se basan en el
modelo cliente/servidor (C/S) en la que los componentes hardware y software se comunican a
través de redes, y un usuario, mediante un programa llamado cliente solicita un servicio a otro
programa llamado servidor que normalmente está situado en una máquina remota. El servidor
recibe la solicitud, la procesa y envía la respuesta a la solicitud del usuario. Un servidor es capaz
de atender a múltiples clientes al mismo tiempo y es el responsable de consultar la información y
procesarla de acuerdo a las solicitudes de los clientes.
Para que esto funcione, es necesaria una estandarización y una arquitectura de referencia basada
en servicios de información y cuyos componentes estandarizados e interoperables permiten las
operaciones más habituales solicitadas por los usuarios de la información geográfica. En el caso
que se refiere a este tema, hay una serie de geoservicios que se realizan gracias a diferentes
aplicaciones especializadas. Los geoportales son un ejemplo de servicio que agrupa diferentes
aplicaciones cliente especializadas que permiten acceder a la variedad de geoservicios
implementados en las IDE como son los servidores de mapas, de catálogo, de metadatos y de
nomenclátor. Un cliente puede ser tanto un navegador de Internet que consulta un geoportal, como
un programa de GIS especializado o incluso un dispositivo móvil desde el que se accede a la
información.
La arquitectura Web se caracteriza por ser una arquitectura cliente-servidor en la que los clientes
(como pueden ser los navegadores Web) realizan peticiones a servicios Web, que procesan las
peticiones de los navegadores (realizadas a través del protocolo HTTP) y devuelven un resultado
(páginas HTML, imágenes, XML, etc.).
El Lenguaje de Marcas Extensible o XML (eXtensible Markup Language) es un metalenguaje

extensible de etiquetas. XML ocupa un importante rol en el intercambio de información
estructurada de una amplia variedad de datos, incluyendo la información geográfica, que facilita la
compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil.
XML fue creado para estructurar, almacenar y enviar información. No solo se utiliza en la Web, sino
también en bases de datos, editores de texto, hojas de cálculo, etc.
XML se utiliza en las tecnologías IDE, en la descripción de los servicios web de OGC y en la
descripción de los conjuntos de datos a través de sus metadatos.
GML está basado en la gramática XML y fue creado con el objetivo de describir objetos
geográficos reales o abstractos para facilitar el intercambio a través de Internet. Permite la
inclusión de información sobre localización y forma del objeto, o datos no espaciales que describen
características del objeto geográfico.
Gracias al trabajo desarrollado por organizaciones como OGC e ISO, ha sido posible la definición
de una arquitectura de referencia, cuando hablamos de las IDE, basada en servicios de
información, independiente de la tecnología con que se implementen.
Cada uno de los geoservicios de una IDE está disponible a través de sus propias reglas de
comunicación. Dichas reglas constituyen el interfaz con el cliente y son el medio mediante el que
se realizan las peticiones al servidor. Las peticiones que realiza el programa cliente utilizan una
sintaxis estandarizada de acuerdo con las especificaciones, y es independiente de cómo lo
resuelva el servidor. Debido a que la comunicación con un geoservicio se realiza mediante una
interfaz estandarizada, un geoservicio puede utilizar otro geoservicio y también un cliente puede
utilizar la respuesta de un geoservicio para otro geoservicio.
La arquitectura más básica para una IDE consiste en un servidor que cumpla con las funciones de
servidor web para ofrecer geoservicios y que al mismo tiempo, tenga acceso a los datos
directamente. También existen otras arquitecturas más complejas que permiten que haya
diferentes servidores de bases de datos para grandes volúmenes de información, servidores web
dedicados, servidores para geoservicios especializados, servidores especializados para la
conexión de Internet, cortafuegos y servidores de seguridad para controlar el acceso a la
información. Por la parte de cliente, podemos agruparlos en 2:
• Clientes pesados: permiten acceder a múltiples formatos de información geoespacial, como

bases de datos, formatos vectoriales, raster, servicios de mapas,… y visualizar esta
información, consultar sus propiedades, actualizarla, realizar análisis, generar mapas para
imprimir, etc. Se pueden considerar las herramientas más avanzadas de las que dispone
un usuario para el manejo de información geográfica.
• Clientes ligeros: permiten acceder a la información geográfica en un entorno Web. Este

tipo de productos son utilizados para construir desde sencillos visores Web, hasta
completos geoportales.
Figura 4: Arquitectura básica de una IDE
Un nodo IDE se sustenta sobre una infraestructura tecnológica y un equipamiento adecuado a los
requisitos que tiene que cumplir. La disponibilidad de los servicios, su rendimiento y su usabilidad
van a depender en gran medida de esa estructura, por lo que se hace necesario realizar un
esfuerzo importante para definir adecuadamente cada uno de los componentes.
A grandes rasgos, se estima como condición necesaria, la consideración de los siguientes

elementos:
• Centro de proceso de datos (CPD).
• Entornos de desarrollo, preproducción y producción.
• Arquitectura de sistemas que garantice la alta disponibilidad, siguiendo los principios de

redundancia y escalabilidad.
• Sistemas de almacenamiento.
• Equipo de operación como responsable de la gestión y administración del CPD.
5. Servicios web de una IDE
La Arquitectura Orientada a Servicios (SOA) es el paradigma de computación distribuida

consistente en la definición de la funcionalidad mínima y necesaria, de acuerdo con los requisitos
particulares de cada usuario, de servicios independientes y disponibles.
La visión IDE es una aproximación a SOA, en la que las interfaces estandarizadas de servicios son
la clave para permitir que los servicios geoespaciales puedan comunicarse entre sí de una manera
interoperable, en respuesta a las necesidades de los usuarios.
Dentro de los servicios de datos geoespaciales que se describen en la Directiva INSPIRE se

corresponden con servicios de red:
• Servicios de visualización (son los que muestran la información geográfica representada

cartográficamente): permiten, como mínimo, mostrar conjuntos de datos espaciales,
navegar, acercarse o alejarse mediante zoom, desplazamiento o superposición visual de
estos datos, así como ofrecer su información asociada y los símbolos convencionales con
los que se representan. En esta categoría entran WMS y WMTS.
• Servicios de localización (son los catálogos de metadatos de datos y servicios): posibilitan

la búsqueda de conjuntos de datos espaciales y servicios partiendo del contenido de sus
metadatos, además de mostrar el contenido de estos metadatos. Es lo que se conoce
como CSW.
• Servicios de descarga: permiten descargar copias de conjuntos de datos espaciales o

partes de ellos, además pueden ofrecer la posibilidad de edición de estos conjuntos de
datos. En esta categoría entran los servicios WFS.
• Servicios de transformación: transforman los datos espaciales con vistas a lograr su

interoperabilidad. Los servicios de transformación se pueden clasificar en diferentes áreas
de funcionalidad, por ejemplo, servicios que transforman formatos de datos (por ejemplo de
un formato propietario a GML), servicios de transformación de sistemas de referencia de
coordenadas (CRS) o servicios de transformación de esquemas lógicos de los datos (de un
modelo de datos propietario al modelo de datos establecido por INSPIRE). En este grupo
también se encuentran los servicios de geoprocesamiento (WPS).
• Servicios que permitan el acceso a servicios de datos espaciales: permiten definir los datos
de entrada y de salida o un flujo de trabajo que espera un servicio espacial, o definir una
cadena de servicios que combine múltiples servicios. Asimismo, permite definir la interfaz
de un servicio web que gestione flujos de trabajo o cadenas de servicios.
• Otros servicios, como el Servicio de Nomenclátor (Gazetteer) que permite localizar un

elemento geográfico (a través de sus coordenadas) a partir de su nombre.
Entrando en un mayor nivel de detalle, vamos a nalizar cada uno de los siguientes servicios:
• Servicio de visualización de mapas e imágenes (WMS, WMTS).
• Servicio de catálogo de metadatos (CSW).
• Servicio de descarga de objetos geográficos (WFS).
• Servicios de geoprocesamiento (WPS).
• Servicios de observación de sensores (SOS).
5.1. El servicio de visualización de mapas e imágenes (WMS, WMTS)
La visualización de mapas e imágenes, se puede considerar la operación más básica que realizan
los SIG. Para visualizar la información geográfica, es necesario soportar los formatos en los que se
puede encontrar almacenada dicha información. Asimismo, se deben gestionar los distintos
sistemas de referencia espacial a los que pueden estar referidos los datos. Se ha de definir
también el modo en que se representa la información (simbología y estilos).
El Servicio de Visualización, también conocido por las siglas WMS produce mapas en la web de
forma dinámica a partir de información geográfica. El WMS genera una imagen digital como una
representación de la información geográfica que esta almacenada en una base de datos, adaptado
para la visualización en una pantalla de ordenador. Por tanto, esta imagen digital no consiste en
los propios datos, sino en una imagen de los mismos.
Además de los aspectos propios de un entorno local, el servicio de visualización de mapas e

imágenes en web (WMS) ha de disponer de un conjunto de operaciones en su interfaz que
permitan explotarlo de una forma eficiente, abierta y estandarizada.
Figura 5: Ejemplo de utilización del servicio WMS desde gvSIG
El servicio de mapas teselado o Web Map Tile Service (WMTS) sirve mapas digitales utilizando
teselas (representación pictórica rectangular de datos geográficos, normalmente parte de un
conjunto de tales elementos, cubriendo una extensión contigua espacialmente) de imágenes
predefinidas. Tiene niveles de escala predefinidos y en cada nivel de escala un número de teselas
o imágenes. Este servicio puede ser más rápido y eficiente que los servicios WMS.
5.2. El servicio de catálogo de metadatos (CSW)
El catálogo mejora el acceso a los datos, permitiendo su localización por temáticas, palabras clave,
localización geográfica, fecha, formato, escala, organización, ranking de más visitados y últimas
novedades. El catálogo es dinámico y está en continuo crecimiento.
Los servicios de catálogo y de visualización (descrito en el punto anterior), están estrechamente

relacionados por los casos de uso más habituales.
Figura 6: Catálogo de metadatos de la IDEE
El Catálogo de datos del IDECV contiene en la actualidad más de 500 metadatos, donde se
describen los datos espaciales, se muestran miniaturas y el acceso a visores. Se basa en
GeoNetwork. Forma parte la Infraestructura de Datos Espaciales de España (IDEE) y ofrece
información relativa a la información geográfica (datos y servicios) del ICV y de otros organismos
que aportan información a la IDECV.
Los metadatos generados por el ICV cumplen con el Núcleo Español de Metadatos (NEM). Los
metadatos conformes con la normativa permiten su interoperabilidad, no solo en el territorio
español sino también en el ámbito europeo.
Figura 7: Catálogo de metadatos de la IDECV
5.3. El servicio de descarga de objetos geográficos (WFS)
El Servicio de Descarga WFS define las operaciones web para la consulta, acceso y edición los
objetos geográficos (Features en inglés) vectoriales.
Por tanto, el servicio Web Feature Service WFS está relacionado con los datos de tipo vectorial, y
a través de él se sirven directamente las entidades de un dato vectorial con sus geometrías y datos
alfanuméricos asociados. Desde este punto de vista, acceder a un servicio WFS es similar a
acceder a una capa vectorial cualquiera o a una base de datos, ya que el SIG puede recuperar la
información correspondiente (tanto la componente geográfica como la temática de cada entidad) y
operar con ella.
Si el estándar WFS permite obtener de un servidor datos vectoriales en forma de entidades, el

estándar Web Coverage Service (WCS) hace lo propio con datos raster.
5.4. El servicio de geoprocesamiento (WPS)
Del mismo modo que hemos visto que dentro del paradigma IDE se pueden servir datos, podemos
analizar que también pueden servirse procesos sobre esos datos. Así pues, existen procesos
remotos a los que los clientes pueden acceder. Es necesaria una estandarización en cuanto a la
forma de acceso a estos servicios y la forma en que los clientes realicen las peticiones de
procesos y la transmisión o definición de los datos que han de tomarse para esos procesos.
El estándar Web Processing Service (WPS) de OGC está enfocado a definir este marco. Define
una interfaz estándar que facilita la publicación de procesos y su uso posterior por parte de
clientes. Cuando hablamos de proceso nos referimos a cualquier algoritmo, cálculo o modelo que
opere sobre datos georreferenciados.
5.5. El servicio de observación de sensores (SOS)
El Servicio estándar de implementación de Observación de Sensores (Sensor Observation Service,

SOS) define una interfaz de servicios web estandarizados para solicitar, filtrar y recuperar las
descripciones, observaciones y la información de sistemas de sensores.
SOS devuelve las respuestas de las observaciones siguiendo la codificación Observations &
Measurements (O&M) y en Sensor Model Language (SensorML) para información sobre sensores.
6. Aplicaciones geoespaciales
Hay una gran variedad de aplicaciones geoespaciales, muchas de ellas Open Source y que se
pueden clasificar de muy diversas formas. Van desde aplicaciones SIG de usuario, ejecutables
desde diferentes entornos, hasta herramientas de programación. A continuación se incluye una
lista no exhaustiva de tipos de aplicaciones/herramientas, con una breve descripción de las más
importantes de cada grupo:
• Clientes SIG de escritorio.
• Aplicaciones SIG en la nube.
• Clientes ligeros Web.
• Bases de Datos Geográficas.
• Servidores Web.
• Catálogo de Metadatos.
• Bibliotecas Geoespaciales.
6.1. Clientes SIG de escritorio
Los clientes SIG de escritorio siguen siendo considerados como las aplicaciones principales del
sector, y hablar de un SIG implica por lo general hacerlo de una aplicación de escritorio antes que
de otro tipo. Normalmente son soluciones en general completas que cubren la totalidad de
necesidades que se presentan en el desarrollo de proyectos SIG, y por ello constituyen las
herramientas primordiales para llevar dichos proyectos a cabo.
• ArcGIS: es, probablemente, el software SIG comercial más utilizado y extendido del
mundo. Es un producto de ESRI, principal referente del sector. Es un sistema muy
completo que permite recopilar, organizar, administrar, analizar, compartir y distribuir
información geográfica.
• GvSIG: es un software Open Source, con origen en la Generalitat Valenciana. Tiene una
interfaz sencilla, es compatible con los formatos más comunes, tanto vectorial como raster.
En términos de IDE, una de las principales características es la implementación de
servicios OGC: WMS, WFS, WCS, WMTS, Servicio de Catálogo y Servicio de
Nomenclátor.
• QGIS: es un proyecto de la Fundación OSGeo y se trata de software Open Source. Permite

manejar formatos raster y vectoriales. Una de sus principales características es su facilidad
de interconexión con muchas bases de datos geoespaciales.
• Otros: GRASS GIS, Kosmo, OpenJump GIS, Saga.
6.2. Aplicaciones SIG en la nube
Incluyen servicios que nos permiten publicar mapas online. Estos sistemas están revolucionando la
sector al permitir que cualquier persona con datos SIG pueda publicar y compartir con todo el
mundo sus mapas web e incluso crear aplicaciones de mapas web interactivas.
• ArcGIS Online: es un gestor de contenido colaborativo, basado en tecnología cloud, que

permite crear y publicar mapas, aplicaciones, datos y cualquier tipo de información
geoespacial.
• CartoDB: es un software Open Source. Tiene dos partes fundamentales, un editor para
importar datos, crear mapas temáticos y publicarlos, y una plataforma que permite utilizar
varias APIs para construir conjuntos de datos geoespaciales más complejos y poder crear
nuestras propias aplicaciones.
• MapBox: es un software Open Source que permite diseñar y publicar mapas en múltiples
medios de una manera fácil y accesible. Utiliza los datos de callejero de OpenStreetMap.
• My Maps: es una herramienta que permite crear de una manera sencilla mapas sobre la
base de Google Maps para poder compartirlos fácilmente. Se necesita tener una cuenta de
Google.
• Otros: QGIS Cloud, GIS Cloud, MapHub.
6.3. Clientes ligeros web
Es una aplicación en Internet con la que podemos visualizar y tratar la Información geográfica a
través de unas herramientas básicas de manipulación y navegación. La mayoría son Open Source.
• Openlayers: cuenta con licencia BSD, y no tiene dependencia de servidores de mapas

concretos. Está construido con clases JavaScript. Ofrece una interfaz de usuario
simplificada que puede acceder a servicios WMS y WFS de forma transparente para el
usuario y desarrollador. Destaca por la gran cantidad de herramientas ya implementadas y
su simplicidad de uso.
• MapBender: cuenta con licencia GNU/GPL. Es un cliente Web construido en JavaScript

que ofrece un interfaz de usuario configurable no dependiente de ningún servidor de
mapas concreto. Constituye un completo GeoPortal, con unas facilidades de configuración
y administración muy potentes.
• MapFish: cuenta con licencia BSD. Es un framework muy completo y flexible para construir
aplicaciones Web.
• Otros: Cartaro, Geomajas, GeoMoose.
6.4. Sistemas gestores de bases de datos geográficas
Una Base de Datos Geográfica es un conjunto de datos geográficos organizados de tal manera
que permiten la realización de análisis y la gestión del territorio dentro de aplicaciones de Sistemas
de Información Geográfica (SIG). Además, se utiliza de soporte para la implantación de servicios
geográficos relacionados con las Infraestructuras de Datos Espaciales (IDE). La mayor parte de los
Sistemas Gestores de Bases de Datos Geográficas (SGBDG) son de tipo relacional.
• ArcSDE (Spatial Database Engine): es un sistema gestor de bases de datos espaciales,

propiedad de ESRI. Los datos espaciales pueden ser utilizados como parte de una
geodatabase. Permite manejar datos espaciales en varios formatos de bases de datos
comerciales (IBM DB2, Informix, Microsoft SQL Server y Oracle) u Open Source, como
PostgreSQL.
• PostGIS: es una base de datos multiplataforma, con licencia GNU/GPL. Ofrece soporte
espacial a la base de datos objeto-relacional PostgreSQL. Puede ser usada como base de
datos subyacente para SIG y aplicaciones de cartografía web. Es la base de datos espacial
Open Source más ampliamente utilizada.
• MySQL Spatial: es una extensión de MySQL, cuya instalación y manejo es muy sencillo. Es
una base de datos que se encuentra por defecto en la mayoría de servicios de hosting y
suele ser la puerta de entrada de muchos desarrolladores.
6.5. Servidores web
• ArcGis for Server: es la herramienta de ESRI. ArcGIS for Server incluye Portal for ArcGIS,
que facilita la creación y compartición de mapas y aplicaciones en muy poco tiempo. Portal
for ArcGIS también ofrece Web AppBuilder for ArcGIS para que se puedan crear
aplicaciones web intuitivas que se ejecuten en cualquier lugar, en cualquier dispositivo sin
escribir una sola línea de código.
• MapServer: proyecto Open Source que permite crear mapas de contenidos para los
usuarios. Probablemente es el servidor de mapas más usado en el mundo. Destaca su
ligereza y facilidad de despliegue.
• MapGuide: proyecto Open Source, consistente en una plataforma web que proporciona a
los usuarios la posibilidad de publicar mapas y servicios web en internet. Incluye soporte a
la mayoría de los formatos geoespaciales de ficheros, bases de datos y estándares.
• GeoServer: también de tipo Open Source, permite servir mapas y datos de diferentes
formatos para aplicaciones Web, ya sean clientes Web ligeros, o programas SIG de
escritorio. GeoServer es la implementación de referencia de los estándares OGC: WFS,
WCS y WMS.
• Otros: MapProxy, QGIS Server, Deegree.
6.6. Catálogo de metadatos
• GeoNetwork: es una aplicación Open Source, con licencia GNU/GPL, para gestionar
catálogos de recursos georreferenciados. Proporciona funciones avanzadas de edición y
búsqueda de metadatos. Incorpora un visor web de mapas interactivo.
• PyCSW: es un software Open Source, que permite al usuario publicar catálogos de

metadatos en la web, usando interfaces y formatos basado en estándares. Es fácil de
configurar en un servidor web Apache. Es una implementación en Python del estándar
CSW de OGC.
6.7. Bibliotecas geoespaciales
• GDAL: es una biblioteca Open Source. Proporciona herramientas para convertir y procesar
un amplio abanico de formatos de datos geoespaciales, tanto vectoriales como raster. Se
basa en una biblioteca C++ multiplataforma, accesible a través de numerosos lenguajes de
programación. Es la biblioteca de acceso a datos espaciales más usada.
• Sextante: es una biblioteca de algoritmos de análisis de datos espaciales escrita en Java y

Open Source, disponible para varios softwares SIG (incluyendo gvSIG). Contiene más de
trescientas operaciones para procesar datos vectoriales o raster, y también tablas.
• Otras: GeoTools, GEOS, GeoBatch
7. Conclusiones/Resumen
A lo largo del tema se ha tratado la importancia y la necesidad de hacer interoperable y accesible,

al público en general, la información geográfica.
La aparición y difusión de las Infraestructuras de Datos Espaciales supuso un punto de inflexión en

este ámbito.
El objetivo principal de las IDE es integrar la información espacial de los diferentes organismos a
través de tecnologías, políticas, acuerdos institucionales, datos y servicios estandarizados que
permitan su acceso, manejo, intercambio y distribución a través de Internet.
La legislación europea (Directiva INSPIRE) y su transposición al ordenamiento jurídico español

mediante la LISIGE, crean un marco legal para su desarrollo.
Normalmente una IDE se materializa a través de un Geoportal o sitio web que ofrece aplicaciones
de visualización, catálogo y nomenclátor
Las IDE están compuestas por una serie de elementos que podemos agrupar en: geográficos
(Datos y Metadatos), tecnológicos (Estándares, Servicios e Infraestructura de comunicaciones),
políticos (Políticas) y sociales (Usuarios).
Entre los servicios que ofrece una IDE destacan:
• Servicio de visualización de mapas e imágenes (WMS,WMTS).
• Servicio de catálogo de metadatos (CSW).
• Servicio de descarga de objetos geográficos (WFS).
• Servicios de geoprocesamiento (WPS).
• Servicios de observación de sensores (SOS).
Finalmente, hay una gran cantidad de aplicaciones geomáticas de tipos diversos, entre las que
destacan los clientes SIG de escritorio como aplicaciones principales del sector, al tratarse de
soluciones en general completas. La práctica totalidad de estos tipos de aplicaciones están
íntimamente relacionadas con el campo de las IDE.
(1) Directiva 2007/2/CE del Parlamento Europeo y del consejo de 14 de marzo de 2007 por la que
se establece una infraestructura de información espacial en la Comunidad Europea
(Inspire)
(2) Ley 14/2010, de 5 de julio, sobre las infraestructuras y los servicios de información geográfica
en España (LISIGE).
(3) Bernabé-Poveda, M.; López-Vázquez C. (2012) Fundamentos de las Infraestructuras de Datos

Espaciales (IDE) Ed. UPM-Press.
(4) Olaya, V (2014). Sistemas de Información Geográfica.
(5) Santos Preciado, J. (2002). El tratamiento informático de la información geográfica. Ed. UNED
(6) Echeverría Martínez., M. (2001) Las infraestructuras de datos espaciales, experiencias en su

implantación. Boletic.
(7) Varios autores (2016). Temario del curso Infraestructura de Datos Espaciales, del Instituto
Geográfico Nacional.
Enlaces de interés:
http://www.opengeospatial.org/
http://www.ign.es/
http://www.idee.es/
http://inspire.ec.europa.eu/
http://www.icv.gva.es/
http://terrasit.gva.es/val/
http://mappinggis.com/
https://langleruben.wordpress.com/
http://www.esri.com
https://commons.wikimedia.org
https://es.wikipedia.org
http://www.gvsig.com/
Tema 36. Gestión de los datos corporativos.
Almacén de datos (data-warehouse). Arquitectura
OLAP. Minería de datos. Arquitecturas y técnicas
de procesamiento masivo de datos (big data)
Francisco Manuel Rangel Pardo

Colegiado 0393
A lo largo del presente capítulo, vamos a describir los componentes que conforman los
sistemas de información, especialmente desde la perspectiva de los niveles de
decisión organizativa de los que forman parte o a los que dan soporte. Cada uno de
estos sistemas proporcionará una tipología diferente de fuentes de información, que
junto con fuentes externas de reciente aparición como las redes sociales, o la internet
de las cosas (IoT, de sus siglas en inglés Internet of Things), conformarán un
repositorio que, debidamente transformado y almacenado en lo que se conoce como
almacenes de datos (data-warehouse), supondrá la materia prima esencial para tareas
como el procesamiento analítico (OLAP) y/o la extracción de patrones (minería de
datos). Finalmente, analizaremos la evolución de la tecnología hasta lo que en la
actualidad se conoce como big data: un nuevo mundo de oportunidades para las
organizaciones donde se coloca el dato como epicentro organizativo.
1. Gestión de los datos corporativos
Desde la década de los 90 que vivimos una era de revolución tecnológica -entendiendo por
tecnología “la totalidad de los medios que las personas emplean para proporcionar bienestar y
subsistencia humana” (Hayes y Wheelright, 1985)- que ha sido promovida, entre otros, por los
siguientes factores:
• La constante disminución de los precios en los sistemas informáticos, frente a su

incremento en capacidades (Moore, 1965).
• El fenómeno de la globalización, propiciando que las empresas alcancen economías de

escala y alcance (Bradley et al., 1993).
• La democratización de las comunicaciones (Inose y Pierce, 1984), propiciada por Internet y

las redes sociales, junto al auge de lo que se viene conociendo en los últimos años como
big data.
Previa a esta revolución tecnológica, la información sólo podía estar en un lugar determinado en un
momento dado. Su acceso, distribución y compartición con los encargados de tomar las decisiones
podía llegar a ser muy costosa. Los cambios que propician esta revolución -disminución de precios,
aumento de capacidades, globalización y big data- también implican la necesidad de un cambio
organizativo en la gestión de los datos.
Tomando como referencia la dirección basada en valor (VBM) (Koller, 1994), toda organización
debe maximizar su generación de valor a partir de los recursos que tiene disponibles. Esto se
observa en el caso de una empresa privada que debe maximizar la diferencia entre el beneficio
generado y el coste requerido para ello, así como en el caso de una administración pública, que
con los recursos de los que dispone, debe maximizar por ejemplo la calidad y variedad de los
servicios proporcionados a los ciudadanos. En la actualidad, uno de estos recursos son los datos
disponibles a las organizaciones, datos que provenientes de diversas y variadas fuentes, pueden
convertirse en datos corporativos para la toma de decisiones. Es por ello que estos datos van a
formar parte esencial del ciclo de planificación, control y toma de decisiones por el cual se gobierna
toda organización.
A lo largo del presente capítulo, vamos a describir los componentes que conforman los sistemas de
información, especialmente desde la perspectiva de los niveles de decisión organizativa de los que
forman parte o a los que dan soporte. Cada uno de estos sistemas proporcionará una tipología
diferente de fuentes de información, que junto con fuentes externas de reciente aparición como las
redes sociales, o la internet de las cosas (IoT, de sus siglas en inglés Internet of Things),
conformarán un repositorio que, debidamente transformado y almacenado en lo que se conoce
como almacenes de datos, supondrá la materia prima esencial para tareas como el procesamiento
analítico (OLAP) y/o la extracción de patrones (minería de datos). Finalmente, analizaremos la
Gestión de los datos corporativos
evolución de la tecnología hasta lo que en la actualidad se conoce como big data: un nuevo mundo
de oportunidades para las organizaciones donde se coloca el dato como epicentro organizativo.
1.1. Los componentes del sistema de información
Los sistemas de información corporativos se pueden analizar desde diferentes perspectivas. En

este punto interesa el enfoque sobre lo que se conoce como la perspectiva conceptual de su
estructura (Arjonilla y Medina, 2002). En ella, se pueden diferenciar cinco componentes: hardware,
software, datos, métodos y personas.
• Hardware, o subsistema físico: Consiste en todos los componentes físicos que conforman
el sistema y que proporcionan las capacidades de entrada y salida (interacción) tanto con
usuarios humanos como con otros sistemas, así como el almacenamiento y procesamiento
de programas y datos. En este subsistema se encuentra la CPU, la memoria RAM, los
discos duros, teclados, ratones, pantallas, tarjetas de red, cableado, etcétera.
• Software, o subsistema lógico: Consiste en los programas y rutinas que utilizan el sistema
físico para el tratamiento de los datos y la interacción con otros sistemas y personas. En
este subsistema se encuentra el sistema operativo, las aplicaciones ofimáticas, sistemas
de gestión, compiladores, herramientas de diseño, de programación, etcétera.
• Datos: Consiste en el conjunto de datos que almacena, procesa y proporciona el sistema.

Estos datos pueden provenir de diferentes fuentes, como se estudiará a lo largo del
capítulo, y se pueden obtener bien porque los introduzca un usuario (e.g. introducción de
datos en formularios de los sistemas de gestión, edición de vídeo, etc.), los obtenga el
sistema automáticamente (e.g. procesos de crawling de páginas web, lectura de sensores,
etc.) o los genere el propio sistema mediante procesamiento de otros datos (e.g. procesos
ETL, conversión de formatos, compresión de ficheros, business intelligence, IoT, etc.).
• Métodos y procedimientos: Es el conjunto de rutinas organizativas que definen el uso de

los sistemas. Por ejemplo, los procedimientos para convertir datos contables en informes
de dirección, o métodos definidos para integrar información de fuentes externas como la
oficina de estadística (INE) o el clipping de prensa.
• Operadores humanos: Engloba a todo el personal que gestiona y utiliza los sistemas. Sin
entrar en detalle, se puede dividir en personal técnico encargado de configurar, gestionar y
mantener los sistemas informáticos, y personal operativo encargado, cada uno en su nivel
de decisión, de utilizar los sistemas para sacarles el máximo provecho (generación de
valor).
1.2. Niveles de decisión y sistemas de información
Los operadores --subsistema humano-- utilizan la información capturada y procesada por los
sistemas para la toma de decisiones en el ámbito organizacional. El proceso de toma de
decisiones está influido por la percepción del riesgo, por lo que los que deben tomar dichas
decisiones, por lo general, tratarán de reducir el mismo. El concepto de riesgo viene a su vez
asociado a la falta de certeza en la información disponible a la hora de tomar la decisión, por lo que
se tratará de reducir esta incerteza para así tener una percepción más realista del riesgo a asumir.
La sobrevaloración del riesgo puede producir bloqueo en la toma de decisiones, lo que es en sí
mismo un riesgo, y la infravaloración puede tener aún peores consecuencias. Los sistemas de
información ayudan a reducir la incerteza en los diferentes niveles de toma de decisiones, de modo
que los decisores pueden tener una aproximación más realista al riesgo que deberán asumir.
De manera general, podemos discernir entre tres niveles de toma de decisiones. En cada uno de
ellos se tiene un horizonte temporal y un nivel de riesgo diferente, así como un diferente nivel de
detalle y variedad en las fuentes de información:
• A nivel de alta dirección las decisiones tomadas son estratégicas, lo que involucra una
perspectiva temporal de largo plazo donde la gestión del riesgo toma una consideración
especial por la mayor incertidumbre en lo que sucederá. Los sistemas de información en
este nivel deben proporcionar datos resumidos de diferentes fuentes de información. Por
ejemplo, datos macroeconómicos de actualidad política, económica, tecnológica y social
(Aguilar, 1967) o microeconómicos como información sobre la competencia, sobre los
clientes, los proveedores, los productos sustitutivos y los complementarios (Porter, 1979),
además del funcionamiento de la propia empresa, a modo de dashboards o presentaciones
resumidas que resalten los aspectos clave.
• A nivel de dirección táctica las decisiones tomadas implican la puesta en marcha y

seguimiento de las pautas estratégicas dictaminadas por el nivel estratégico, donde tanto
el plazo temporal como el riesgo asumido son menores. Los sistemas de información en
este nivel deben proporcionar información del funcionamiento de las diferentes unidades
organizativas (e.g. departamentos, regidurías, etc.), así como un seguimiento cercano de la
consecución de los objetivos marcados. El nivel de detalle es agregado, permitiendo
analizar en detalle bajo petición aquellos aspectos que se desee, pero proporcionando una
visión conjunta de sus componentes (e.g. ventas por departamento o por cliente, gasto de
personal por departamento, costes por proveedor), por ejemplo, mediante sistemas de
cuadros de mando o business intelligence.
• A nivel operativo las decisiones tomadas son a corto plazo con el objetivo de alinear el día
a día de la organización con los objetivos marcados por el nivel táctico. Los sistemas de
información en este nivel se centran en la recopilación de datos, su procesamiento y
consulta. El nivel de detalle es máximo, permitiendo procesar cualquier unidad informativa
de la compañía (e.g. una venta, un salario, un pago a proveedor, etc.). El riesgo en el nivel
operativo es mínimo.
1.3. Fuentes de información
Los niveles de decisión en la empresa dejan entrever la necesidad de acudir a diferentes fuentes
de información (e.g. estadísticas oficiales, noticias, conversaciones en redes sociales, etc.) que en
ocasiones complementen los datos disponibles y producidos por la propia organización (e.g. datos
de los sistemas de producción, gestión y control). Se pueden identificar, entre otras, las siguientes
fuentes de información:
1.3.1. Base de datos corporativa
Por regla general, serán bases de datos relacionales que se alimentarán de la operativa con los
sistemas de producción, gestión y control de la organización. Se las conoce también como bases
de datos transaccionales, puesto que su propósito es dar soporte a las transacciones diarias de
la organización. Existe una correspondencia entre los niveles de toma de decisión expuestos
anteriormente, y el objeto de cada una de estas bases de datos. Por ejemplo, en niveles
operativos y tácticos, como sistemas de producción y control, estarían los sistemas de diseño
asistido por ordenador (CAD), sistemas de fabricación integrada por ordenador (CIM) o sistemas
de procesamiento electrónico de datos (EDP), sistemas de planificación de recursos (ERP),
sistemas de automatización de oficinas (OAS) o sistemas de flujo de trabajo o workflow. A nivel
táctico y estratégico se encontrarían los sistemas de información para la gestión (MIS), sistemas
de soporte para la decisión (DSS, GDSS), sistemas de información para ejecutivos (EIS), sistemas
expertos (SE), sistemas de inteligencia de negocio (BI), inteligencia de fuentes abiertas (OSINT) o
sistemas de minería de datos (data mining). Algunos tipos especiales y/o específicos de bases de
datos corporativas pueden ser las bases de datos espaciales, temporales, documentales y
multimedia:
• Las bases de datos espaciales contienen información sobre el entorno espacial de los
objetos. No sólo se corresponden con bases de datos geográficas con información de
ciudades, topografías o similares, sino en un sentido más amplio, permitirían almacenar
todo tipo de información donde la principal característica es la relación espacial entre sus
elementos. Por ejemplo, mapas estelares, cartas de navegación, atlas cerebrales,
imágenes médicas, redes de transporte o redes información.
• Las bases de datos temporales contienen información relacionada a través del tiempo,
desde diferentes momentos puntuales hasta intervalos. Estas bases de datos están
optimizadas para el análisis de series temporales, donde no sólo es importante la
secuencia de ocurrencia de los eventos, sino también su periodicidad y estacionalidad.
Pueden ser útiles para almacenar incidencias de todo tipo, análisis de colas o similares.
• Las bases documentales contienen atributos para definir y describir documentos

textuales. Estas bases de datos pueden ser no estructuradas, donde se almacenan los
textos sin procesar, estructuradas, donde se almacena el resultado de procesar dichos
textos y se crea una estructura como podría ser una ficha bibliográfica, o mixtas. Una de
las librerías más utilizadas como base documental por su potencia para crear lo que se
conoce como índices invertidos es Lucene. Además, la proliferación de bases de datos
NoSQL con orientación documental sugiere que se dedique un apartado específico a las
mismas.
• Las bases de datos multimedia almacenan vídeos, sonidos e imágenes. Con la

proliferación de dispositivos móviles con capacidad de captura multimedia y los servicios
como Youtube para almacenar vídeo o Flicker para fotografía, entre otros muchos, las
bases de datos con contenidos multimedia están en auge. Uno de los principales retos con
el que tienen que lidiar es el gran tamaño que pueden llegar a alcanzar estos documentos.
1.3.2. La web, las redes sociales y otras fuentes OSINT
Con la proliferación de la Web, especialmente la Web 2.0, donde son los propios usuarios los que
generan y consumen los contenidos, convirtiéndose en lo que se conoce como prosumers, y aún
más con el auge de las redes sociales, la cantidad de contenidos que se producen a partir de
opiniones y preferencias de los usuarios hacen de Internet una fuente datos de incalculable valor.
Son lo que se conoce como fuentes abiertas y de ahí el nombre de OSINT como la generación de
inteligencia a partir de fuentes abiertas (de sus siglas Open Source Intelligence). Y es que, en
estas fuentes, los usuarios, de manera libre, espontánea y sin restricciones --al menos a priori--
emiten sus juicios, sus preferencias y opiniones sobre todo tipo de productos, eventos y/o
personas. Aunque son muchas las fuentes abiertas, podemos considerar los siguientes grupos:
• Blogs: Son sitios web que se actualizan de manera periódica con contenidos publicados
por uno o más autores según su propio criterio y pautas editoriales. Abarcan un amplio
abanico de posibilidades, desde blogs corporativos hasta personales, pasando por medios
de comunicación similares a la prensa. Existen servicios que proporcionan el alojamiento y
el mantenimiento tecnológico de los blogs, como pueden ser Blogger
(https://www.blogger.com) o Wordpress (https://www.wordpress.com), aunque la mayoría
de blogueros “profesionales” optan por conseguir su propio dominio y gestionar su propio
blog, lo que les proporciona mayor libertad y capacidad de personalización.
• Foros: Son sitios web que permiten a los usuarios discutir y compartir información
relevante sobre un determinado tema. Es un sitio de discusión libre e informal, a veces
moderada en cuanto a la posibilidad de publicación o no, pero dejando libertad a los
participantes para expresarse en su propio estilo. Este tipo de sitios ofrece una información
valiosa a determinadas organizaciones por su orientación y especialización temática. Un
ejemplo relevante de foro es StackOverflow (http://stackoverflow.com/) en el ámbito del
desarrollo de software. En la actualidad, el concepto de foro ha evolucionado hacia un mix
foro-blog donde poder compartir y discutir sobre determinados temas. En este sentido,
Reddit (https://www.reddit.com/) es un servicio que ofrece la posibilidad de crear
comunidades de discusión, algo muy utilizado por ejemplo por el partido político Podemos
desde sus orígenes (https://www.reddit.com/r/podemos/).
• Redes sociales de micro-blogging: Son similares a los blogs, pero la cantidad de

información que se puede compartir es limitada, lo que propicia la espontaneidad y la
velocidad en la transmisión de información: esto la convierte en la red por excelencia para
la generación de contenidos frescos de actualidad, así como para la auto-organización de
protestas y actos colectivos. La red de micro-blogging por excelencia es Twitter, que
permite a sus usuarios compartir lo que hacen o lo que están pensando con la limitación de
140 caracteres por actualización (tuit), donde se pueden compartir textos, hashtags,
menciones a otros usuarios y urls a documentos de otros medios. Twitter es a su vez una
red social, ya que permite la relación entre usuarios. En esta red, cada usuario puede
seguir a tantos otros usuarios como quiera, conformando la red de seguidos (friends) del
usuario. Así mismo, a un usuario le pueden seguir tantos usuarios como estén interesados,
conformando así su red de seguidores (followers). De este modo, la red social que se
conforma es asimétrica, no dirigida, donde de manera independiente se conforma la red de
seguidos y la de seguidores, de manera libre, sin necesidad de consenso entre usuarios.
Twitter proporciona múltiples accesos vía API (Aplication Programming Interface) a sus
motores de búsqueda, erigiéndose como fuente de información de la que obtener una
visión del entorno, y siendo por lo tanto una de las redes preferenciales en OSINT.
• Redes sociales: El principal cometido de las redes sociales es conectar a usuarios.

Existen las redes sociales personales, lúdicas, donde las relaciones predominantes son de
amistad, y las redes sociales profesionales, donde la relación predominante es el contacto
y/o la colaboración. Ejemplo representativo de las primeras es Facebook. Facebook es una
red social compuesta por usuarios, páginas, grupos y eventos, y la relación entre todos
ellos. Ejemplo representativo de las segundas es LinkedIn, que permite conectar con
colegas de todo el mundo a modo de agenda de contactos, mantener comunicaciones
privadas con ellos, así como pertenecer a grupos, y compartir y comentar en ellos como si
de foros profesionales se tratase.
• Redes sociales multimedia: Lo que en un principio nace como plataforma para compartir
contenido multimedia --fotografías, vídeos, audios-- pronto se convierte en red social al
incorporar características de las mismas como la posibilidad de seguir a otros usuarios y/o
de comentar sus contenidos. En los últimos años han proliferado multitud de redes de este
tipo como Youtube o Vimeo para vídeo, Ivoox, Sound Hound o Spotify para audio, o Flickr,
Instagram o Pinterest para fotografías. En este tipo de redes, tanto personas como
organizaciones hacen acopio de toda su creatividad para compartir sus creaciones.
Además, existen otras muchas redes que se pueden englobar en una o más de las anteriores
categorías y que por su especificidad pueden resultar de interés para OSINT: Qitter, Tumblr,
Meetup, Academia, Slashdot, Snapchat, Google+, Change.org, WhatsApp, Telegram, Line, QQ,
WeChat, Qzone, Weibo, Tagged, Habbo, Hi5, SoundCloud, Badoo, Netlog-TWOO, DayliMotion,
VK, Match, Slideshare, etc.
1.3.3. Internet de las cosas (IoT)
Internet de las cosas es un concepto que nace en el MIT (Instituto Tecnológico de Massachusetts)
para referirse a todo un conjunto de dispositivos autónomos capaces de recopilar y transmitir
información a través de internet. Por ejemplo, frigoríficos inteligentes que pueden realizar pedidos
de compra según sus parámetros de stock, gafas de realidad aumentada que se alimentan de
información de internet y la posicionan en el entorno, zapatillas que registran la actividad deportiva
de quién las lleva, dispositivos de monitorización y alerta médica de constantes vitales, televisores
que interactúan con la voz y proporcionan contenidos personalizados, y hasta plantas que tuitean
cuando necesitan agua.
La revolución del internet de las cosas viene de la mano de la mejora en los sistemas de
telecomunicaciones y su mayor penetración territorial, el aumento de las capacidades de proceso a
la par que la disminución en el tamaño de los equipos, la proliferación de sensores más sensibles y
pequeños, y las grandes posibilidades de almacenamiento y proceso que proporciona la nube. Con
ello, el internet de las cosas se erige como una de las tecnologías que van a generar más datos en
los próximos tiempos por lo que pueden ser una fuente de información útil y valiosa para tener en
cuenta en el entorno empresarial. Por ejemplo, un hospital que tiene en tiempo real información de
salud de todos sus pacientes, ingresados o no; un grupo televisivo que tiene información en tiempo
real de la audiencia de los programas e incluso la emotividad de su audiencia (si lo cruza con
comentarios en redes sociales, en ocasiones realizados desde el propio televisor, se convierte en
televisión social); ciudades que ajustan sus semáforos al tráfico real que se produce en cada
momento, con una capacidad de predicción añadida sobre la base de un registro histórico de uso;
y un largo etcétera de ejemplos.
2. Almacén de datos (data-warehouse)
El propósito de las bases de datos transaccionales es el de dar soporte diario a las operaciones de
la organización. Estos sistemas dan soporte por lo tanto a los niveles operativos de decisión. Sin
embargo, según el nivel de decisión se va acercando al ámbito estratégico, las necesidades de
información son diferentes; se requieren sistemas que permitan cruzar, agregar y desagregar la
información para llegar a comprenderla y obtener así el conocimiento necesario para la toma de
decisiones. Además, esta toma de decisiones se debe basar en diferentes fuentes de información,
no todas ellas presentes en el sistema transaccional de la empresa, y muy probablemente de difícil
integración en el mismo.
Figura 1: Almacén de datos. Fuente: Elaboración propia
De ahí surge la necesidad de los almacenes de datos que permitan recopilar información de
diferentes fuentes de manera óptima para su consulta, y separada de los sistemas transaccionales
para no afectar a su operativa diaria. Los decisores requieren analizar el pasado para prevenir el
futuro, por lo que trabajarán con vistas de la información existente. Y es aquí donde los almacenes
de datos se hacen imprescindibles. Un esquema típico de almacén de datos como integrador de
diferentes fuentes de datos se muestra en la Figura 1. En ella se puede apreciar como el almacén
de datos recopila y almacena datos de diferentes fuentes; desde las propias bases de datos
transaccionales de la organización, hasta información de las redes sociales o recopiladas por
dispositivos inteligentes. Pero además, este almacenamiento se realiza con una orientación clara
hacia el análisis y explotación de los datos que contiene, con lo que su utilidad proyecta la
necesidad de definir su arquitectura.
2.1. Modelo multidimensional
El modelo multidimensional es el más comúnmente utilizado para diseñar almacenes de datos. En

este modelo, el concepto central es el hecho. Un hecho pues es un dato o concepto lógico de
interés para la organización. Ejemplos de hechos serían las ventas, el personal de la organización,
o la reputación de una entidad o persona en redes sociales. Un hecho se caracteriza por sus
atributos, que definen cantidades mensurables sobre aspectos del hecho. Tomando en cuenta el
ejemplo de una venta, algunos de sus atributos serían el importe, la cantidad de productos
vendidos, los clientes que compraron, los comerciales involucrados o los territorios afectados. Los
atributos aportan medidas cuantitativas al hecho que definen. Cada uno de estos atributos se
puede detallar o agregar en función de las dimensiones que se le definan. Por ejemplo,
dimensiones asociadas a la venta serían el tiempo en que se efectúa la misma (a diferentes niveles
de agregación como pueda ser el día, la semana, el mes, el trimestre o el año), el lugar de la venta
(de nuevo a diferente nivel de agregación como ciudad, región o país), el comercial que la hizo
(agregando por ejemplo por territorios), o los artículos vendidos (agregando por categoría),
etcétera. En la siguiente imagen vemos un ejemplo de modelo multidimensional del hecho venta.
En la Figura 2 vemos el hecho venta, con los atributos importe y cantidad. Estos atributos
cuantitativos, se pueden agregar y desagregar por las dimensiones tiempo, lugar, producto y/o
comercial, de modo que se pueda responder a preguntas como ¿cuánto ha vendido cada comercial
en cada territorio, distribuido por importe y/o por cantidad?, ¿qué productos son los más vendidos,
distribuidos por territorio y/o por trimestre?, ¿cuáles son los productos preferidos por los clientes de
cada territorio, donde el PIB se encuentre en un determinado rango?, ¿cuáles son los territorios
donde más vende cada comercial, teniendo en cuenta únicamente los territorios no rurales?, o
cualquier combinación de atributos y dimensiones. La representación gráfica de un modelo
multidimensional de tres dimensiones se asemeja a un cubo, por lo que a los modelos
multidimensionales se les suele denominar hipercubos de información.
Figura 2: Modelo multidimensional de la venta. Fuente: Elaboración propia
Se puede apreciar que el modelo multidimensional define los hechos en forma de estrellas, con el
hecho en el centro y las dimensiones en las puntas de la estrella. Existe conceptualmente dos tipos
de estrella: la estrella simple, cuando las dimensiones sólo permiten un camino de agregación o el
copo de nieve, cuando hay caminos alternativos para agregar y desagregar por una dimensión
(como en el caso del tiempo en el ejemplo mostrado).
2.2. Datamart
En el modelo multidimensional definimos los ámbitos de interés de la organización como estrellas,

donde el hecho es el nodo central y de él parten las diferentes dimensiones. Un almacén de datos
estará pues compuesto de diferentes estrellas definiendo cada uno de los hechos --ámbitos de la
organización-- que se desee modelar. Por ejemplo, ventas, personal, reputación, etcétera.
Cada una de estas estrellas es lo que de manera generalizada en la literatura se denomina

datamart. Se entiende pues que un almacén de datos almacena un conjunto de datamarts
modelando hechos con sus propios atributos y dimensiones, y facilitando así las operaciones de
análisis y explotación de los mismos.
2.3. Data lake
El término data lake fue utilizado por primera vez por director técnico de Pentaho James Dixon
para contrastarlo al término datamart común a los almacenes de datos. Es conocida su cita “If you
think of a datamart as a store of bottled watter --cleansed and packaged and structured for easy
consumption-- the data lake is a large body of water in a more natural state. The contents of the
data lake strem in from a source to fill the lake, and various users of the lake can come to examine,
dive in, or take samples” (Dixon, 2015). En las palabras de Dixon se aprecia la principal diferencia
entre datamart, que como vimos es un conjunto de hechos estructurados en modo de estrella que
definen mediante sus atributos y dimensiones la realidad de la organización que se desea analizar,
y el data lake, como almacén no estructurado donde pueden cohabitar tanto datos estructurados
como los datamarts, como información en bruto, sin procesar, para poder ser transformada y
utilizada en cualquier momento, o incluso almacenar de nuevo el resultado de dicho proceso en el
mismo data lake. Es decir, un data lake podrá contener datos estructurados como bases de datos
relacionales, semiestructurados como ficheros csv, xml o json, datos desestructurados como
emails, tuits o artículos de prensa, y datos binarios como fotografías, ejecutables o de cualquier
otro tipo, todo ello de manera centralizada y accesible. La Tabla I muestra las diferencias
principales entre almacén de datos (o conjunto de datamarts) y data lake:
Tabla I: Datamart vs. Data lake. Fuente: Tamara Dull (SAS)
DATAMART DATA LAKE

ESTRUCTURADOS,
ESTRUCTURADOS, SEMIESTRUCTURADOS,
DATOS
PROCESADOS NO ESTRUCTURADOS,
BRUTOS
ESQUEMA A LA ESQUEMA A LA
PROCESAMIENTO
ESCRITURA LECTURA
ELEVADO COSTE
DISEÑADO PARA BAJO
ALMACENAMIENTO PARA GRANDES
COSTE
VOLÚMENES
AGILIDAD BAJA ALTA
SEGURIDAD MADURA MADURANDO
PROFESIONALES, CIENTÍFICOS,
USUARIOS
NEGOCIOS ANALISTAS
Uno de los sistemas más conocidos y utilizados para crear data lakes es el sistema de ficheros
distribuido de Apache Hadoop (HDFS, Hadoop Distributed File Systems), aunque en la actualidad
muchas organizaciones están haciendo uso de repositorios distribuidos como Amazon S3 para la
creación de sus propios data lakes.
2.4. Mantenimiento del almacén de datos. ETL
Tras el diseño e implementación del almacén de datos llega el momento de rellenarlo con los datos
provenientes de las distintas fuentes. Además, este proceso de relleno se deberá realizar en más
de una ocasión, puesto que el almacén de datos tiene como principal misión proporcionar una
visión histórica a los que toman las decisiones para que puedan realizar sus análisis. Esta visión
histórica dependerá del momento de la decisión, y se deberá actualizar periódicamente para
incorporar los últimos cambios ocurridos en las fuentes de datos: por ejemplo, las últimas ventas
realizadas, las últimas conversaciones en la red o las últimas medidas de los sensores. El proceso
de rellenar el almacén de datos se denomina ETL (de sus siglas en inglés Extraction,
Transformation, Load) y se conforma en las tres fases que le dan nombre:
• Extracción: Es el proceso encargado de, a partir de las distintas fuentes de datos

definidas, extraer los datos necesarios para su almacenamiento en el almacén. Este
proceso típicamente consistirá en consultas SQL a la base de datos transaccional,
procesos dump de datos, accesos vía API a fuentes de datos como redes sociales,
portales open data o similares, procesos de wrapping y/o scrapping de páginas web,
digitalización y reconocimiento óptico de caracteres (OCR) de documentos escritos,
etcétera. Por lo general, el resultado bruto de la extracción de fuentes de datos se
almacenará en un repositorio intermedio, sobre el que realizar la siguiente fase de limpieza
y transformación, para su correcta adecuación al almacén de datos. Este repositorio
intermedio puede ser una base de datos relacional o un sistema de ficheros cualquiera, lo
que mejor se adapte al proceso.
• Transformación: Es el proceso encargado de, a partir de los datos brutos obtenidos de las
diferentes fuentes externas, limpiarlos, ordenarlos y estructurarlos para adecuarlos al
modelo definido en el almacén de datos (datamarts). En esta fase se eliminarán datos
redundantes, se realizará una estandarización de formatos (e.g. fechas, divisas, etc.), se
tratarán los datos nulos --por ejemplo, eliminándolos o sustituyéndolos por comodines--, se
normalizarán los datos inconsistentes entre fuentes, según su veracidad y/o confianza en
la fuente, y se podrán crear los metadatos, índices y claves necesarios para una mejor
organización.
• Carga: Es el proceso por el cual, a partir de los datos limpios y preparados del
almacenamiento intermedio, se crean los diferentes datamarts y se rellenan con la
información adecuada. En esta fase se debe tener en consideración el orden de carga de
los datos, cuáles dependen de cuáles, asegurar la consistencia e integridad de los datos y,
si es necesario, se crearán los índices correspondientes a los hechos y las dimensiones
que se podrán explotar.
El proceso ETL se debe diseñar de manera específica para el almacén de datos y las fuentes de
información definidas. Es la fase más costosa de la creación y explotación de un almacén de datos,
y la más sensible, ya que de su calidad va a depender la calidad del resultado. Aunque existen
herramientas que asisten en el proceso de creación de ETL, es el equipo encargado del almacén
de datos quien deberá definir y desarrollar los respectivos módulos de extracción, transformación y
carga.
3. Arquitectura OLAP
El procesamiento analítico en tiempo real (OLAP, On-Line Analytical Processing) requiere de

operaciones en modo consulta para agregar y cruzar gran cantidad de información con el objetivo
de generar conocimiento a partir de los datos transaccionales. Su objetivo, por lo tanto, es ayudar
a la toma de decisiones mediante la aportación de conocimiento, generalmente a modo de

informes. Ejemplos de estos informes podrían ser las ventas por comercial y territorio, el tiempo
medio en la lista de espera de las diferentes especialidades de un hospital o la cantidad de
menciones por temática y destinatario en una red social.
La principal diferencia con el procesamiento transaccional en tiempo real (OLTP, On-Line

Transactional Processing), es que este último consiste en todo tipo de transacciones y no
únicamente consultas. Es el trabajo principal de los sistemas de información cuando registran,
actualizan o eliminan información detallada de las diferentes transacciones de la organización. Por
ejemplo, cuando se introduce una factura, un pedido, un paciente o un diagnóstico. Es el trabajo
diario para el que se ha diseñado el sistema de información. OLAP sin embargo se centra en
operaciones de consulta que, en ocasiones, son costosas por los cruces de información
requeridos. Aplicar pues procesamiento analítico sobre bases de datos transaccionales suele
provocar dos tipos de problemas:
• El primero es que las bases de datos transaccionales no están diseñadas ni estructuradas

para las consultas que se desea realizar en el proceso analítico. Esto va a incrementar la
dificultad en las consultas por tener que seguir la estructura transaccional (claves únicas y
foráneas, tablas de unión n a n, tablas de normalización, etc), y no la estructura lógica de
los datos modelados. Por ejemplo, si se desea obtener agregados de productos más
vendidos, importes de venta por territorio y comercial, o similares, las consultas a realizar
incluirían un conjunto elevado de tablas con sus relaciones.
• Además, consultas complejas como las descritas van a requerir de un tiempo de proceso
elevado, pues en ocasiones, se va a tener que recorrer todas las filas de una tabla para
efectuar los agregados (totales por comercial y territorio). Esto, que en un sistema
dedicado resultaría costoso, si se realiza contra el propio sistema transaccional puede
ocasionar una merma en su rendimiento o incluso el fallo total del sistema.
Tabla II: OLTP vs OLAP. Fuente: Blog Inteligencia de Negocio
OLTP OLAP
OPTIMIZADAS PARA EL REGISTRO OPTIMIZADAS PARA LA
DE DATOS CONSULTA
DATOS AL DETALLE DATOS AGREGADOS
REDUNDANCIA, ESPACIO
NORMALIZACIÓN, REDUCCIÓN DE
EXTRA PARA OPTIMIZAR LA
ESPACIO
RESPUESTA A CONSUTLAS
DATAMARTS: HECHOS Y
TABLAS Y RELACIONES
DIMENSIONES
Es por ello que para efectuar análisis de datos en tiempo real se recomienda la utilización de los
almacenes de datos, tal y como vimos en el apartado anterior. Estos almacenes de datos van a
permitir acceder en modo consulta de una manera eficiente y van a permitir realizar las
operaciones analíticas necesarias para extraer conocimiento.
3.1. Operadores OLAP
Los operadores OLAP van a permitir la explotación avanzada de los almacenes de datos. Los
operadores más importantes son los siguientes:
• Drill: Permite desglosar los datos a partir de una o más dimensiones. Es decir, permiten
entrar a mayor nivel de detalle de los mismos. Por ejemplo, a partir de las ventas de una
empresa, agregadas para verlas por comercial y territorio, permitiría entrar a detalle
territorial bajando de un nivel de agregación superior como es el país, a un nivel de detalle
mayor como es la distribución por ciudad.
• Roll: Permite realizar la operación contraria, es decir, agregar los datos a partir de una o
más dimensiones. Por ejemplo, a partir de las ventas por comercial y territorio, poder
agregar la distribución por ciudades para ver los resultados a nivel de país, un nivel de
agregación superior al anterior.
• Slice & Dice: Permite seleccionar y proyectar datos, concretamente slice permite
seleccionar un subconjunto de los datos, y dice proyectarlo en una nueva vista. Por
ejemplo, dada la distribución por comercial y territorio, permitiría seleccionar un
subconjunto de los comerciales y de los territorios y ver como resultado solo su cruce.
• Pivot: Permite la reorientación de las dimensiones, cambiando filas por columnas, y

recalculando el valor de las celdas. Siguiendo con el ejemplo, se podría cambiar de una
vista de distribución de ventas por territorio agregando por comercial y trimestre, a una
vista de distribución de ventas por comercial, agregando por territorio y trimestre.
Una de las principales características de los operadores OLAP es que se realizan en tiempo real y
no requieren generar un nuevo informe (una nueva consulta SQL, una nueva hoja Excel, etc.), ya
que tras aplicarlo, automáticamente se recalculan los valores de las celdas y se dispone de la
nueva información. Un aspecto importante relativo al rendimiento tendrá que ver con la
implementación que haga el almacén de datos de la arquitectura OLAP.
3.2. Implementaciones OLAP
Dependiendo del modo en que se implementen físicamente los sistemas de base de datos que dan
soporte al almacén de datos, se distingue entre:
• Sistemas ROLAP (Relational OLAP): el almacén de datos se construye sobre una base de
datos relacional. Su principal ventaja es que se puede aprovechar la infraestructura de
bases de datos relacionales de la organización y sus características, como la utilización de
consultas SQL. Esto permite reducir costes de implantación y formación del personal. Sin
embargo, debido a las propias restricciones de los modelos relacionales, para modelar un
datamart con tecnología ROLAP se hace necesario el uso de tres tipos de tablas: las tablas
copo de nieve, que almacenan los datos de cada una de las dimensiones a cada uno de
los posibles niveles de agregación, las tablas de hechos, que almacenan la información de
cada elemento de la vida real que se quiera modelar con claves foráneas a cada una de
las tablas copo de nieve, para poder agregar y desagregar por cada posible dimensión, y
las tablas estrella, que son tablas por cada atributo de los objetos de las tablas de hechos,
con claves foráneas a las tablas de copo de nieve con un atributo por cada nivel de
agregación para dicha dimensión. Como es de suponer, esto aumenta artificialmente el
espacio requerido para modelar el problema. Ejemplos de sistemas ROLAP son
Microstrategy, Informix Metacube y Oracle Discoverer.
• Sistemas MOLAP (Multidimensional OLAP): el almacén de datos se construye sobre

estructuras basadas en matrices multidimensionales. Su principal ventaja es la
correspondencia entre el nivel lógico y el nivel físico, lo que hace que sean por lo general
más eficientes. Sin embargo, sus principales inconvenientes derivan de esta mayor
especialización, como que requieren sistemas específicos, o la necesidad de mayor
espacio físico debido a la mayor desnormalización de los datos, ya que se ajustan al
mundo real sin pensar en restricciones de normalización como se imponen en los sistemas
relacionales. Además, esto último que propicia la ventaja de que existe una
correspondencia más directa entre el mundo real y el sistema que lo modela, también hace
que en caso de que el problema varíe se deba efectuar una reestructuración del sistema
mayor que en un sistema ROLAP. Ejemplos de sistemas MOLAP son Oracle Express e
Hyperion Enterprise.
• Sistemas híbridos HOLAP (Hybrid OLAP), que combinan ambas tecnologías.
Se puede encontrar una comparación entre servidores OLAP en la siguiente página de la

Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_OLAP_Servers.
4. Minería de datos
En (Clark y Boswell, 2000) se define la minería de datos como el proceso de extraer conocimiento
útil y comprensible, previamente desconocido, desde grandes cantidades de datos almacenados
en distintos formatos. De dicha definición se desprenden algunos hechos a considerar:
• El resultado de la minería de datos debe ser conocimiento nuevo.
• Dicho conocimiento debe ser inteligible y susceptible de generar valor para la toma de
decisiones. Que el conocimiento deba ser inteligible no significa que el modelo de
aprendizaje lo sea; por ejemplo, una red neuronal es opaca en cuanto a su funcionamiento,
pero su resultado puede aportar conocimiento para determinar el riesgo de una operación
bursátil.
• La entrada del proceso es una gran cantidad de datos en diversos formatos, a partir de
los cuales se deberá extraer el conocimiento. Este punto es una de las bases que enlaza a
la minería de datos con el big data.
• Y aunque no se menciona de manera explícita en la definición, el proceso de minería se

debe realizar de manera (semi) automática.
La minería de datos tiene relación con diversas disciplinas, confundiéndose en ocasiones con
algunas de ellas. Se puede considerar a la estadística como la madre de la minería de datos, ya
que gran cantidad de terminología, métodos y técnicas provienen de ella: las medidas de
centralidad como la media, la desviación estándar, las distribuciones de frecuencias, los métodos
de validación cruzada o el aprendizaje bayesiano son algunas de ellas. El aprendizaje automático
también tiene una relación estrecha con la minería de datos, ya que proporciona algoritmos que
son capaces de aprender a partir de ejemplos para resolver tareas concretas. La inteligencia
artificial en su concepto más amplio tiene relación con la minería de datos pues le aporta todo lo
relativo al aprendizaje automático, pero también los modelos de representación de los datos
necesarios para que dichos algoritmos puedan aprender. Pero quizás donde existe una relación
más estrecha, tanto que llega a confundir la terminología, es con el proceso de extracción de
conocimiento de bases de datos (KDD de sus siglas en inglés Knowledge Discovery in Databases).
4.1. Fases. Modelo CRISP-DM
La minería de datos se enmarca en un proceso más amplio denominado KDD. Sin embargo, en la
mayoría de ocasiones que mencionamos la minería de datos como disciplina, estamos haciendo
mención a todo el proceso anterior en su globalidad. Teniendo esto en cuenta y con el objetivo de
normalizar una metodología para aproximar tareas de minería de datos, cinco compañías (SPSS,
Teradata, Daimler AG, NCR Corporation y OHRA) proponen en 1996 el modelo CRISP-DM (CRoss
Industry Standard Process for Data Mining). CRISP-DM consta de seis fases altamente
relacionadas entre sí, donde el conocimiento de cada fase alimenta a la siguiente y realimenta a la
anterior.
• Fase 1 Comprensión del negocio: Esta primera fase es esencial para llevar a cabo un
proceso de minería con éxito. En esta fase se marcan los objetivos a conseguir con el
proyecto, el conocimiento que se desea descubrir y para qué será utilizado. Esta fase
determinará las elecciones a realizar en las siguientes fases.
• Fase 2 Comprensión de los datos: Esta segunda fase está íntimamente ligada a la
anterior. Una buena comprensión del negocio beneficiará la comprensión de los datos
disponibles y los necesarios para cumplir el objetivo, y a su vez, una mejor comprensión de
los datos, permitirá comprender mejor el negocio y afinar en los objetivos esperados por el
proyecto.
• Fase 3 Preparación de los datos: En esta fase se recopilan, integran, preparan, limpian y
transforman los datos para adaptarlos a las necesidades marcadas por la comprensión del
negocio y de los datos.
• Fase 4 Modelado: En esta fase se aplicarán los métodos de minería de datos orientados a
resolver el problema concreto planteado en los objetivos del proyecto. La construcción de
los modelos puede implicar tener que transformar los objetivos de nuevo, por lo que son
dos fases que se encuentran íntimamente ligadas.
• Fase 5 Evaluación: En esta fase se evalúa la calidad de los modelos desde dos
perspectivas: la técnica, donde se evalúa la calidad de los resultados obtenidos, y la del
negocio, donde se evalúa el valor que aporta el conocimiento descubierto. Este nuevo
conocimiento realimenta la fase de comprensión del negocio, por lo que puede hacer que
se replanteen los objetivos del proyecto o incluso que se hagan proyectos alternativos.
• Fase 6 Distribución: En esta última fase se dispone de nuevo conocimiento que se

distribuye en la organización para ser incorporado en sus procesos de toma de decisiones.
Cuando se llega a esta fase se consideran cumplidos los objetivos y por lo tanto sólo
queda llevar a la práctica lo que se ha aprendido.
Figura 3: Modelo CRISP-DM. Fuente: CRISP-DM.
4.2. Comprensión del negocio y comprensión de los datos. Tipología de

problemas
Las dos primeras fases del modelo CRISP-DM están muy relacionadas entre sí. Una buena
comprensión del problema desde la perspectiva del negocio ayudará a comprender mejor los
datos, y una buena comprensión de los datos, ayudará a definir mejor el problema desde la
perspectiva del negocio.
En este punto, uno de los principales puntos es determinar a qué tipo de problema hay que
enfrentarse. Que el proyecto de minería sea exitoso dependerá en gran medida de la comprensión
que se tenga del negocio y de los datos disponibles o conseguibles. A continuación, se realiza una
revisión de los tipos de problemas más comunes a los que enfrentarse en un proyecto de minería
de datos, para posteriormente entrar en detalle en algunas de las técnicas más conocidas para
abordarlos. Se considera que los problemas de minería de datos se pueden resolver con dos tipos
de tareas:
• Las predictivas, que tratan de predecir nuevos valores a partir del entrenamiento previo
con datos etiquetados; y,
• Las descriptivas, que parten de un conjunto de valores no etiquetados y tratan de

describirlos.
Sea:
• E el conjunto de todos los posibles elementos de entrada, representando generalmente

como un conjunto de atributos nominales o numéricos A
• A el conjunto de atributos nominales o numéricos de E tal que E=A1xA2x...xAn
• e € E el elemento ejemplo perteneciente a E y representado por la tupla e=<a1, a2, …, an>

donde a € A
• S el conjunto de valores de salida.
4.2.1. Tareas predictivas
En las tareas predictivas se dispone de un conjunto d de elementos etiquetados como duplas

d=<e,s> donde e € E y s € S. Está etiquetado puesto que a cada entrada e se sabe su
correspondencia unívoca con un elemento de salida s. Por ejemplo, clientes con y sin riesgo,
opiniones positivas, negativas o neutras, o sensores y sus rangos de valores. Dentro de este tipo
de tareas podemos encontrarnos con problemas de clasificación, categorización, priorización y
regresión.
• Clasificación: Su objetivo es aprender una función f:E->S que a partir de un conjunto de

elementos de entrada etiquetados d=<e,s> sea capaz de predecir el valor de la etiqueta
para una nueva instancia no etiquetada. Por ejemplo, dado un conjunto de clientes E
representados por una serie de atributos A (edad, ingresos, gastos, nivel educativo…) y un
conjunto S de etiquetas asignadas (riesgo/no riesgo), sea capaz de predecir la etiqueta s
correspondiente para un nuevo cliente e para el que no se dispone de etiqueta.
Si el conjunto S sólo tiene un valor (y generalmente su contrario), se habla de clasificadores

binarios (e.g. es o no spam, es o no cliente de riesgo, es hombre o mujer). Si por el contrario hay
más de un valor (e.g. positivo, negativo y neutro; adolescente, veinteañero, treintañero, etc.), se
habla de clasificadores multiclase. Estos últimos se pueden entrenar para predecir entre las
múltiples clases, o como clasificadores binarios entre cada clase y las demás (estrategia 1 contra
todos).
La salida de la clasificación puede llevar asociada una estimación de la probabilidad de que dicha
clasificación sea la correcta (e.g. este cliente es potencialmente de riesgo con 85% de certeza).
Esto es lo que se conoce como clasificación suave, donde además de la función de estimación
de clase, se aprende otra función con la probabilidad de pertenencia a la misma. Es lo que se
conoce como el estimador de probabilidad. Además de la ventaja que aporta el conocer el grado
de certeza de la predicción, este tipo de clasificadores permiten su combinación mediante rankings
de clasificadores.
• Categorización: En este caso, en lugar de aprender una función que asigna cada ejemplo
e una clase en exclusiva, en la categorización se pueden asignar tantas clases como sea
necesario. Un ejemplo típico de esta tarea es la de etiquetado semántico, donde por
ejemplo, a una entrada de un blog se le asignarían tantas etiquetas como temáticas se
detectasen en el mismo. De igual manera que con los clasificadores, en la categorización
se puede aprender un estimador de probabilidad y por lo tanto realizar una categorización
suave.
Se puede ver el problema de la categorización como un problema agregado de clasificadores

binarios, donde para cada categoría se dispondría de un clasificador binario que asignaría o no la
categoría correspondiente. Volviendo al ejemplo del blog, si se dispone de tres etiquetas o
temáticas, la categorización por clasificadores binarios consistiría en aprender tres clasificadores
que determinasen si el blog pertenece o no a cada una de esas etiquetas.
• Priorización: El problema es similar al de la clasificación/categorización, pero se basa en

obtener una lista ordenada de preferencias a partir de los datos, habiendo aprendido
previamente de ejemplos ordenados. La dificultad estriba precisamente en el aprendizaje
de estas secuencias de elementos, pero el trasfondo es similar a los casos anteriores.
Una aplicación interesante sería en los sistemas de recomendación, donde se proporciona al

usuario una lista de elementos afines a sus gustos, pero dicha lista se presenta ordenada.
Piénsese en resultados de una búsqueda y la recomendación de consultas similares, o la elección
de un producto (no sólo un producto físico a comprar, también uno virtual a consumir como una
canción o una película), donde los productos similares recomendados estuvieran ordenados por
afinidad a las preferencias del usuario.
• Regresión: La definición matemática es similar a la de la clasificación, es decir, aprender

una función que asigne un único valor de salida a cada ejemplo de entrada d:E->S. Sin
embargo, la diferencia fundamental es que los valores de S sólo pueden ser numéricos, a
diferencia de la clasificación, donde los valores de S son atributos nominales denominados
clases. Esta propiedad de la regresión permite trabajar en un entorno continuo como es el
de los números reales R, y la función de predicción puede ser tan compleja como sea
necesaria, no sólo lineal.
La regresión puede servir para predecir las ventas del próximo trimestre dependiendo de una serie
de factores actuales, o para identificar la edad que tiene una persona en función de otras
características como el lenguaje que utiliza. Aunque los valores resultantes son numéricos y
pueden estar en un rango continuo, se puede fácilmente convertir un problema de regresión en uno
de clasificación simplemente creando rangos que se correspondan con determinadas clases. Así
pues, una regresión para identificar la edad de una persona podría convertirse en una clasificación
si creamos rangos como niños (de 0 a 13 años), adolescentes (de 13 a 18 años), jóvenes (de 18 a
25 años), etcétera.
4.2.2. Tareas descriptivas
En el caso de las tareas descriptivas, los ejemplos e € E se presentan sin etiquetar ni ordenar, o lo
hacen de manera parcial. Ejemplos de tareas descriptivas son el agrupamiento, la correlación, las
reglas de asociación y la detección de anomalías.
• Agrupamiento: también conocido por su denominación inglesa (clustering), consiste en

obtener conjuntos de elementos que sean lo más homogéneos dentro del conjunto y lo
más heterogéneos con respecto al resto de grupos. Esto es, conjuntos de elementos que
se parezcan mucho entre sí y poco con respecto a los demás.
La principal diferencia con la clasificación es que a priori no se sabe cada elemento a qué conjunto
pertenece, ni siquiera los conjuntos que puede haber. Es el proceso de aprendizaje el que decide
ambas cosas: qué grupos hay (y por lo tanto cuántos) y quién pertenece a cada grupo.
Una aplicación de este tipo de técnicas es la segmentación de clientes en marketing. Según

determinados comportamientos (atributos), se procede a agruparlos según determinadas
características comunes y diferentes al resto. Cuando se dispone de un nuevo cliente, se calcula a
qué grupo pertenecería, y se podría inferir atributos (comportamientos) de dicho cliente que no
conocemos a priori por la similitud con los otros clientes de su grupo.
En las técnicas de agrupamiento también existe el concepto de suave y de estimador de

probabilidad, con lo que cada instancia o ejemplo de entrada no sólo se asignaría al
correspondiente grupo (el más probable), sino que se dispondría de la probabilidad de pertenencia
a cada uno de los grupos, lo que permitiría al supervisor humano tener mayor conocimiento de lo
que está sucediendo, e incluso incorporar correctores.
• Correlación: El objetivo es determinar si dos instancias o elementos <e1, e2> € E, o

alguno de sus atributos E = A1xA2x...xAn, está relacionado de algún modo, y cuál es la
dirección de dicha relación.
La correlación se limita a atributos numéricos, y generalmente el resultado se determina por un

valor numérico indicando la similitud o diferencia entre ambos, que suele comprenderse en el
rango [-1, 1]. Un valor que tiende hacia el extremo izquierdo (-1) indicará una correlación negativa
donde al crecer una variable, la otra decrece, mientras que un valor que tiende hacia el extremo
derecho (1) indicará correlación positiva, donde una variable crecerá si lo hace la otra. Valores
cercanos a 0 implican no correlación entre ellos, es decir, cualquier relación es fruto del azar.
Es importante hacer notar que la correlación únicamente determina la relación entre dos
elementos, nunca la causalidad. Esto significa que son bidireccionales y no orientados, a diferencia
de la causalidad, que implicaría unidireccionalidad y orientación. Esta confusión es uno de los
errores más cometidos en análisis de datos, especialmente en entornos big data donde, por la
sobreabundancia de datos, se pueden encontrar correlaciones entre cualquier par de variables.
• Reglas de asociación: Las reglas de asociación permiten obtener relación entre variables
cuyos atributos son nominales, a diferencia de la correlación que únicamente lo permitía
con atributos nominales. Las reglas de asociación se han aplicado principalmente a
descubrir patrones en bases de datos, y han sido y son una de las principales tareas en
minería de datos. Con ellas se pueden obtener reglas del tipo “si compró este producto hay
tanta probabilidad de comprar este otro”. Existe una regla de asociación muy famosa que
se desprende de un estudio realizado por Wal-Mart que afirmaba que “los clientes que
compran pañales son 5,33 veces más propensos a comprar cerveza (que los que no
compran pañales)”. Este hecho, quizás debido a las largas noches de los padres
primerizos, aportó un conocimiento sustancial a Wal-Mart para reorganizar sus estanterías
y poner ambos productos más cerca, aumentando así sus ventas.
Además de poderse aplicar a atributos nominales, las reglas de asociación tienen otra diferencia
sustancial con la correlación, y es que en este caso sí que puede existir implicación causal. Es
decir, las reglas de asociación pueden ser bidireccionales, o unidireccionales y orientadas. En esta
categoría se suelen incluir las dependencias funcionales, diferenciándose en que éstas consideran
todos los posibles valores. Por ejemplo, sabiendo el nivel de ingresos, el rango de edad, la etnia, el
nivel de estudio y si está casado, se puede determinar el riesgo de morosidad de un cliente.
• Detección de valores e instancias anómalas: A diferencia de la mayoría de los métodos

anteriores, donde se aprende por la existencia de determinados patrones que se hacen
patentes por su frecuencia de aparición conjunta, esta tarea consiste en encontrar aquellos
valores, o aquellas instancias (ejemplos), que no sean similares a ninguna de las demás.
Esta tarea se suele utilizar para detectar fraudes, fallos o intrusos en sistemas, comportamientos
extraños y/o diferenciados, etcétera. Por ejemplo, fraudes en el uso de tarjetas de crédito porque el
momento, el lugar y/o el importe sean anómalos con respecto a su uso normal, fallos en las redes
de transmisión porque el nivel de ruido, la latencia y/o el orden de llegada de los paquetes sea
diferente a su distribución normal, intento de acceso no autorizado al sistema porque la
combinación de caracteres utilizados en la contraseña, el número de intentos y/o el intervalo entre
intentos difieren de los usos anteriores, o detección de pederastas porque el estilo de escritura, la
frecuencia y/o las palabras utilizadas no se correspondan con el perfil del usuario que dice ser.
4.3. Preparación de los datos. Modelos de representación.
Tras la definición del problema a resolver y la identificación de en qué tipo de problema de minería
de datos se encuadra, es el momento de preparar los datos para poder aplicar las técnicas de
modelado correspondiente. La preparación de los datos va a involucrar dos fases bien
diferenciadas: el pre-procesamiento y la representación. Se presentan en orden inverso para

mejorar su comprensión.
Para poder aplicar las diferentes técnicas de minería de datos que veremos en el siguiente punto,
se debe representar los objetos sobre los que se quiera efectuar la minería mediante lo que se
conoce como modelo de espacio vectorial. Por ejemplo, si el problema que queremos resolver es
el de predecir si un nuevo cliente tiene riesgo de ser moroso, el objeto sobre el que realizaremos la
minería será el objeto cliente. Este objeto vendrá definido por una serie de características como su
sexo, edad, nivel salarial, nivel educacional, lugar de residencia, puesto en la organización, tamaño
de la organización en la que trabaja, etcétera.
Tabla III: Ejemplo objeto CLIENTE. Fuente: Elaboración propia
ATRIBUTO / CARACTERÍSTICA POSIBLES VALORES

SEXO HOMBRE / MUJER
EDAD >18
NIVEL SALARIAL <15k; 15-20K; 20-30K; 30-50K; >50K
NIVEL EDUCACIONAL SIN ESTUDIOS; GRADO; MASTER; DOCTOR
LUGAR DE RESIDENCIA PAÍS y CIUDAD
La representación vectorial de un cliente vendrá dada por los valores que tomará cada uno de los
atributos que lo definen. Por ejemplo,
Francisco = {hombre, 39, ?, doctor, valencia}
La representación anterior se denomina vectorial porque convierte cada objeto en un vector de

características definidas por su valor concreto para ese ejemplo concreto. Es por ello que a este
proceso se le denomina de extracción de características. Se puede apreciar en el ejemplo
anterior que existen diferentes tipos de características, concretamente:
• Características numéricas, que pueden ser enteras o reales, limitadas o no a un intervalo,

como es el caso de la edad.
• Características nominales, con o sin orden, como pueden ser el resto de características del
modelo: sexo, nivel salarial, nivel educacional, lugar de residencia.
Generalmente los datos de los que disponemos para construir el espacio vectorial de los objetos a
minar no suele estar adecuado a los requerimientos del algoritmo que vamos a utilizar, pese a que
en la fase ETL se haya realizado limpieza y normalización de los mismos. Por ejemplo, algunos
algoritmos no trabajan bien, o incluso lo imposibilitan, con valores faltantes y/o nulos (como el
salario en el caso del ejemplo). Otros algoritmos sólo permiten trabajar con atributos numéricos,
mientras que otros no permiten utilizar más que atributos nominales. A continuación enumeramos
algunas de las técnicas que se suelen aplicar para pre-procesar los datos y adecuarlos a los
requerimientos de modelado.
• Discretización: Permite convertir atributos numéricos a nominales, mediante lo que se

conoce como técnicas de binning. Para ello los atributos numéricos se agrupan en rangos
predefinidos y se asigna la etiqueta correspondiente. Ejemplo de discretización lo hemos
visto en el caso del nivel salarial o el tamaño de la organización, donde en lugar de un
valor numérico absoluto tenemos la pertenencia a uno de esos rangos.
• Numerización: Permite convertir atributos nominales a numéricos, generalmente

asignando valores numéricos consecutivos a los diferentes valores nominales de la
característica. Esto es necesario en casos como el análisis multivariante o la regresión
lineal, que sólo trabajan con atributos numéricos.
• Valores faltantes: En ocasiones los algoritmos no trabajan bien con valores faltantes por
lo que se deben convertir a valores aptos para el modelo. Por ejemplo, si de un cliente no
tenemos su nivel salarial, se podría crear una etiqueta más que indique que no se conoce
(NSC) para que el modelo pudiera tratar con dichos valores.
• Reducción de la dimensionalidad: Cuando el modelo vectorial es muy grande, porque se

dispone de muchos atributos, es posible que necesitemos reducir la dimensionalidad
porque los algoritmos de minería no trabajen bien con tantas características (aumenten
considerablemente el coste computacional). Esto suele suceder en problemas de alta
dimensionalidad como son el tratamiento de imágenes, donde una representación vectorial
puede consistir en los valores RGB-alfa para cada uno de los millones píxeles de una
imagen, o en procesamiento del lenguaje natural donde una representación vectorial puede
consistir en la frecuencia de aparición de cada palabra del texto. Existen múltiples técnicas
de reducción de la dimensionalidad, de entre las que destacan las técnicas basadas en
entropía (se seleccionan aquellas características que más novedad aportan al modelo), las
basadas en ganancia de información (similar a las anteriores, son aquellas
características que aportan más información), o el análisis de componentes principales
(que efectúa una proyección a un espacio multimensional de menor dimensionalidad que el
original pero manteniendo la relevancia de los atributos).
4.4. Técnicas de modelado
Una vez identificado el tipo de problema al que nos enfrentamos en un proyecto de minería de
datos, debemos decidir con qué algoritmo aproximar su solución. Se puede considerar que hay dos
tipos de aproximación algorítmica al aprendizaje automático: retardada (o perezosa, de lazy
learning) y anticipativa (o ansiosa, de eager learning).
4.4.1. Métodos perezosos de aprendizaje automático
En el caso perezoso, el algoritmo de aprendizaje automático espera hasta disponer del ejemplo
sobre el que aplicar el conocimiento (clasificación, regresión…). Una de sus principales ventajas es
que resuelve los problemas de manera local, según se van produciendo los ejemplos, lo que
permite adaptarse de manera rápida y sencilla a los ejemplos sobre los que tiene que trabajar.
Esto es así porque no requiere de un entrenamiento previo, que puede resultar costoso, y que
puede sobreajustar el algoritmo a los datos de entrenamiento, perdiendo capacidad de

generalización a nuevos ejemplos. Una desventaja es que a cada nuevo ejemplo el algoritmo debe
reaprender, frente a un método anticipativo que únicamente debe aplicar los cálculos aprendidos,
con lo que se puede ver reducido su rendimiento, algo crítico especialmente en entornos big data.
Uno de los algoritmos perezosos más conocidos es el de los k-vecinos más próximos. Otros
algoritmos son la regresión logística local o el razonamiento basado en casos.
4.4.2. Métodos anticipativos de aprendizaje automático
En el caso anticipativo, el algoritmo de aprendizaje construye un modelo a partir de un conjunto de

datos de entrenamiento, y ante un nuevo ejemplo, aplica el modelo construido para resolver el
problema (clasificación, regresión…). Una de sus principales ventajas es el alto rendimiento a la
hora de aplicarlo en producción, ya que el modelo ya está aprendido y aplicarlo sobre ejemplos
nuevos es muy rápido. Sin embargo, su principal inconveniente es la posibilidad de sobreajuste a
las muestras de entrenamiento, con lo que si las muestras sobre las que aplicar el modelo varían
significativamente, puede que su precisión se vea mermada. Para minimizar este problema, se
suele reentrenar el modelo cada cierto tiempo para adaptarlo a la variabilidad en los datos.
A continuación, se describen brevemente las aproximaciones al aprendizaje automático anticipativo

más conocidas. Sin embargo, existen multitud de técnicas diferentes. El campo de la minería de
datos y el aprendizaje automático es muy amplio y activo en la investigación, por lo que se
recomienda consultar la bibliografía para ampliar en el tema.
• Métodos bayesianos: Se basan en el teorema de Bayes, por el cual se puede calcular la

probabilidad a posteriori de la clase en base a las probabilidades a priori aprendidas de los
datos para cada una de las características que los representan. Los métodos bayesianos
son fáciles de programar, son muy expresivos y permiten trabajar con incertidumbre (de
hecho, la probabilidad nace para ello).
• Árboles de decisión: Los árboles de decisión permiten aprender en base a ejemplos,

mediante la construcción de reglas de decisión simples que se disparan según umbrales de
una determinada característica. En el proceso de entrenamiento se va dividiendo los
ejemplos hasta construir un árbol donde cada división se efectúa en base a un umbral de
decisión para una característica determinada (e.g. edad < 40 vs. edad > 40). A la hora de
clasificar un nuevo ejemplo se comenzará en el nodo raíz del árbol y se seguirán las
condiciones de sus nodos hasta llegar a un nodo hoja, que se corresponderá con una de
las posibles clases. Para evitar el sobreajuste al entrenamiento, construyendo árboles que
aprendan exactamente los ejemplos de entrada, pero no tengan gran capacidad
discriminatoria, se efectúa lo que se llama una poda a un determinado nivel.
• Redes neuronales artificiales (RNA): El origen de las RNA fue para intentar emular lo que
sucedía en el cerebro humano. Así pues, se definen las neuronas como funciones simples
de proceso de una señal de entrada hacia una señal de salida. La neurona se activa
cuando la señal de entrada supera un determinado umbral, propagando su valor a la
salida, o no lo hace. El entrenamiento se produce por la técnica de backpropagation que
ajusta los pesos o umbrales de cada neurona a partir de los ejemplos dados. Son métodos
opacos, poco explicativos, pero que en la actualidad están produciendo buenos resultados
en gran variedad de tareas en el campo del deep learning.
• Máquinas de vectores soporte (SVM por sus siglas en inglés Support Vector Machines):
Tratan de determinar el hiperplano que separa las muestras entre las diferentes clases, de
forma que el margen entre la distancia entre las muestras más próximas de cualquier clase
y dicho hiperplano se maximice. Las SVM hacen uso de métodos basados en kernels para
operar en espacios de alta dimensionalidad, sin necesidad de calcular todos los puntos de
manera explícita.
• Algoritmos evolutivos (dentro de los cuales se encuentran los genéticos): Tratan el

problema de la optimización sobre la base de la teoría de la evolución. Se parte de un
conjunto de soluciones al problema, soluciones que se cruzan entre sí de manera no
determinística, simulando lo que sería una mutación. De entre las nuevas soluciones se
seleccionan aquellas que mejores resultados ofrecen (optimización), y se repite el proceso,
simulando la reproducción de los individuos más fuertes (soluciones óptimas).
4.4.3. Meta-clasificadores
Siguiendo la filosofía de Epicuro, “si más de una hipótesis es consistente con los datos, debemos
mantenerlas todas”, los meta-clasificadores permiten combinar los resultados obtenidos por
diferentes algoritmos de aprendizaje automático, de modo que la salida del meta-clasificador es
una ponderación entre las salidas de los diferentes clasificadores y cuyo objetivo es conseguir
sinergia entre los mismos, es decir, obtener un resultado superior a la utilización individual de
cualquiera de ellos.
La combinación de clasificadores se puede realizar de múltiples maneras, de forma simplificada,

respondiendo al concepto de voto. Un votador mayoritario consistiría en, dado el resultado
proporcionado por los diferentes clasificadores, seleccionar aquel resultado que más veces
aparece en la salida de los clasificadores individuales. Esto sin embargo obliga a tener un número
superior de clasificadores que de clases (problema de multiclasificación), puesto que cada
clasificador podría dar un resultado y no haber consenso. Existen diversas técnicas para mejorar el
proceso:
• Asignación de pesos a cada clasificador, de modo que el votador estaría ponderado

dando mayor importancia a los clasificadores que se consideren más precisos, como si de
un conjunto de asesores se tratara sobre los cuales tenemos depositado un nivel diferente
de confianza.
• Aprendiendo una función de voto, en lugar de optar por el resultado mayoritario. En este
caso, el votador se podría sustituir por otro clasificador que, en función de las predicciones
realizadas por los clasificadores individuales y la clase real, aprendiera un modelo de
votación. La principal ventaja es que dependiendo de los datos el modelo aprenderá un
votador ponderado mucho más ajustado que el que le podamos fijar mediante pesos. Sin
embargo, su principal desventaja es que estamos acumulando errores de clasificación. Se
puede mejorar aprendiendo no sólo a partir de los resultados de los clasificadores
individuales, sino además de todas las características que describen a los datos. Por
ejemplo, aprendiendo como un clasificador más, y además a partir de las salidas de los
anteriores.
• Reordenando la salida de clasificadores suaves, es decir, si los clasificadores

individuales en lugar de proporcionar una salida única, proporcionaran las n mejores
predicciones con su porcentaje de certeza, el meta-clasificador podría combinar la salida
de todos los clasificadores y reordenarlas en función de posibles pesos. En este caso, sólo
tendríamos que aprender la mejor distribución de pesos posibles para el meta-clasificador.
4.5. Evaluación
Tras la creación de los modelos se deben evaluar para obtener sus estadísticas de rendimiento. Se
puede entender el rendimiento desde dos perspectivas: la del coste computacional de su aplicación
y desde la capacidad de generalización y producción de conocimiento útil y aprovechable.
Las técnicas de evaluación van a depender de la tipología de problema que se esté resolviendo,
por lo que existirán técnicas de evaluación de modelos de clasificación, clustering, regresión,
reglas de asociación, etcétera. A continuación, se detalla para cada tipología cuales son las
técnicas más utilizadas.
4.5.1. Evaluación de clasificadores (categorizadores)
La evaluación de modelos de clasificación parte del siguiente esquema, donde el modelo se

construye con unos datos de entrenamiento, a partir de los cuales se aprende, y se evalúa con
unos datos de pruebas, diferentes a los datos de entrenamiento para evitar sobre ajuste, y que nos
ayudarán a determinar la calidad de modelo.
Existen diferentes modelos de partición para conseguir los conjuntos de entrenamiento y pruebas.
No obstante, es imprescindible que cualquiera de estos modelos garantice una total separación de
los datos entre entrenamiento y pruebas para que no se produzca lo que se conoce como
sobreajuste: si existen datos en el conjunto de pruebas que fueron utilizados para entrenar los
modelos, cuando se evalúe con ellos, el modelo podrá dar mejores resultados de los reales por
haber aprendido sobreajustándose a los datos. Destacan tres modos de conseguir estas
particiones: split, cross-validation y bootstrap.
Figura 4: Aprendizaje y evaluación de clasificadores. Fuente: Elaboración propia
• Evaluación por split: Se divide el conjunto de datos en dos subconjuntos --entrenamiento y

pruebas-- con una ratio prefijada que generalmente resulta ser 30/70, es decir, el 30% de
los datos para entrenamiento y el 70% restante para pruebas.
• Cross-validation o validación cruzada, llamada también n-fold cross-validation o

validación cruzada en n capas: Consiste en realizar n particiones de los datos en
entrenamiento y pruebas, donde cada vez se toma 1/n elementos para entrenamiento y 9/n
elementos para pruebas (estas proporciones pueden variar, e incluso admitir repetición de
elementos entre iteración). Un valor común de n es 10, aunque en los casos más costosos
se suele reducir a 5. El objetivo de la validación cruzada es evitar el posible sesgo que
pudiera tener una partición cualquiera como en el caso del split, realizándolo múltiples
veces y obteniendo la media. Sin embargo, uno de los errores más comunes es el del
sobreajuste al entrenamiento, donde la aplicación de la validación cruzada --las particiones
en los datos-- se realiza tras haber entrenado los modelos con todo el conjunto de datos,
en lugar de reentrenar los modelos con los datos de cada partición.
• Bootstrap: Cuando se dispone de pocos ejemplos para entrenar y evaluar el modelo, se

puede utilizar esta técnica para aumentar la cantidad de ejemplos de manera artificial. Para
ello se efectúa un muestreo con reposición y posteriormente se aplica, por ejemplo, la
técnica de validación cruzada.
Entre las diferentes formas en que podemos evaluar un modelo de clasificación, son de especial
interés dos: evaluación por precisión y evaluación por costes.
4.5.1.1. Evaluación por precisión
En la evaluación por precisión se prima que el modelo aumente la cantidad de ejemplos bien
clasificados. Destaca la medida accuracy.
• Accuracy (precisión): Se define como el número de ejemplos correctamente clasificados

dividido por el número total de ejemplos.
• Error muestral: Sería la inversa de la accuracy (1 - accuracy), y proporciona el porcentaje

de muestras o ejemplos mal clasificados.
La medida accuracy (o desde la perspectiva contraria, el error muestral) permite fácilmente ver el
rendimiento de un clasificador, aunque adolece de ciertos problemas. Por ejemplo, en el ámbito
médico podríamos tener un clasificador que ante unos síntomas como mucosidad, fiebre y falta de
apetito siempre diagnosticara gripe. Su accuracy sería muy cercana al 100%, pero ocurriría que un
paciente con meningitis sería diagnosticado con gripe y moriría. Esto es lo que se conoce como un
Falso Positivo, y puede tener un coste muy superior a cualquier otro tipo de error. Así nace la
necesidad de la evaluación por costes.
4.5.1.2. Evaluación por costes
En la evaluación por costes prima que el modelo efectúe una predicción minimizando el coste
(riesgo) de la misma. Para la evaluación por costes conviene construir una matriz con los posibles
errores que se pueden producir. Es lo que se conoce como matriz de confusión. Supongamos un
clasificador binario que clasifique a un paciente como meningitis sí (caso positivo) o no (caso
negativo). La matriz de confusión quedaría de la siguiente manera:
Tabla IV: Matriz de confusión. Fuente: Elaboración propia
Predicción
Negativo Positivo
Negativo a b
Clase real
Positivo c d
El significado de las letras en la matriz es el siguiente:
• a representa los casos que han sido correctamente predichos como casos negativos
(pacientes sin meningitis que se han clasificado como que no padecen meningitis).
• b representa los casos que incorrectamente se han clasificado como positivos (pacientes
sin meningitis clasificados como que padecen la enfermedad).
• c representa los casos que incorrectamente se han clasificado como negativos (pacientes
con meningitis diagnosticados erróneamente como que no padecen meningitis).
• d representa los casos que correctamente se han clasificado como positivos (pacientes con
meningitis que correctamente se han identificado como tales).
Asociado a cada uno de los valores a, b, c y d tenemos un coste, con lo que deberemos multiplicar
cada uno de los valores anteriores por su coste y quedarnos con aquel clasificador que minimice el
resultado. Es importante notar que nos referimos a coste como función que asigna mayores pesos
a los peores casos, no tiene por qué corresponderse con coste económico. Sin embargo, traducirlo
a coste económico suele simplificar su entendimiento y facilitar la toma de decisiones.
En el caso de que no sea posible disponer de una matriz de costes para aprender los modelos, se
hace uso de la técnica del análisis ROC (Receiver Operating Characteristic). Para ello se calculan
las siguientes ratios a partir de la matriz de confusión:
• True positive (TP) o verdaderos positivos, es la proporción de casos positivos que son
correctamente clasificados.
(1)
• False positive (FP) o falsos positivos, es la proporción de casos negativos que fueron
incorrectamente clasificados como positivos.
(2)
• True negative (TN) o verdaderos negativos, es la proporción de casos negativos que

fueron correctamente clasificados.
(3)
• False negative (FN) o falsos negativos, es la proporción de casos positivos que fueron
incorrectamente clasificados como negativos.
(4)
Y con ellas se representa una curva que confronte los False positive (FP) frente a los True positive
(TP) en un espacio real de dos dimensiones con valores entre 0 y 1. Un clasificador será mejor
cuanta más área cubra bajo la curva ROC.
4.5.1.3. Medidas alternativas
Importadas de otras áreas como la de la recuperación de información, y a partir de la matriz de

confusión presentada anteriormente y las medidas TP, FP, TN, FN, se dispone de otra serie de
medidas que permiten destacar diferentes aspectos del funcionamiento de los clasificadores.
Concretamente:
• Precision (precisión): Indica la habilidad del clasificador para no asignar como positiva una
muestra que es negativa. En el ejemplo, sería la capacidad del clasificador para no
determinar que un paciente tiene meningitis cuando no la tiene. Se define como la relación
entre los verdaderos positivos (TP) frente a la suma de verdaderos positivos (TP) y falsos
positivos (FP).
(5)
• Recall (alcance, recuerdo): Indica la habilidad del clasificador para encontrar todas las
muestras positivas, es decir, la capacidad de clasificar correctamente a todos los pacientes
que tienen meningitis y no descartarlos como que no la tienen. Se define como la relación
entre el número de verdaderos positivos (TP) frente a la suma de verdaderos positivos (TP)
y falsos negativos (FN).
(6)
• F-score: Puesto que evaluar un modelo en base a dos medidas puede resultar complejo,
especialmente a la hora de comparar diferentes sistemas, se define una medida que
combina ambas, por regla general, como la media armónica, aunque se puede decidir
efectuar un ajuste de peso diferente según convenga. Por ejemplo, si se le da más
importancia a no dejar de diagnosticar un caso de meningitis frente a equivocarse y
diagnosticar como meningitis un caso que no lo es, se optaría por incrementar el peso
correspondiente a recall.
(7)
4.5.2. Evaluación de modelos de regresión
Los modelos de regresión se diferencian de los de clasificación en que, en lugar de asignar una
clase única y nominal, se puede asignar un valor en un intervalo numérico continuo. La evaluación
en este tipo de técnicas trata de encontrar un valor que proporcione la similitud entre el valor
predicho y el valor real, para un conjunto de ejemplos de validación.
Dado un conjunto de pruebas T de n ejemplos, el vector y de resultados predichos por el modelo

aprendido, y el vector ŷ de valores reales para cada ejemplo de pruebas (ground truth), el valor x̄
como la media de los valores predichos, y el valor ȳ como la media de los valores reales de
regresión, las medidas más utilizadas para evaluar el modelo de regresión son las siguientes:
• Error cuadrático medio (MSE, Mean Squared Error), que consiste en sumar los errores
cuadráticos entre la salida del modelo y la función real:
(8)
• Raíz del error cuadrático medio (RMSE, Root Mean Squared Error), que consiste en
realizar la raíz cuadrada de la medida MSE para normalizar a la magnitud real de los
errores (que con MSE efectuamos el cuadrado):
(9)
• Error absoluto medio (MAE, Mean Absolute Error), que trata de limitar el peso de los
errores más extremos:
(10)
• Error cuadrático relativo (RSE, Root Squared Error), que pretende dar el mismo peso a
errores de magnitud 10 en una predicción de 100, que errores de 1 en una predicción de
10.
(11)
• Correlación producto-momento de Pearson (PC, Pearson Product-Moment Correlation),

que aunque no es una medida de evaluación específica de la regresión, ha sido utilizada
en el estado del arte de tareas que involucran la regresión con una buena aceptación
académica. El PC o coeficiente de Pearson como también se le conoce, proporciona una
medida de correlación entre dos variables en un rango de entre [-1,1], con la interpretación
que se proporcionó cuando se trató de los problemas de correlación en el apartado
anterior. La formulación del PC, cuando se trata de una muestra r, es la siguiente:
(12)
4.5.3. Evaluación de modelos de clustering/agrupamiento
En el caso del clustering no se dispone de etiquetas asociadas a los datos por lo que la evaluación
hará uso del concepto de verosimilitud (likelihood) que implicará maximizar un valor determinado
de similitud (inverso al concepto de distancia) entre los elementos agrupados conjuntamente. Es

decir, minimizar la distancia (e.g. el error cuadrático) entre cada ejemplo xi y el centroide del grupo
ck al que se asigna:
(13)
También se suele utilizar el concepto de entropía, que define la cantidad de información que aporta
el modelo, y su objetivo en dicho caso es maximizarla.
4.5.4. Evaluación de modelos de reglas de asociación
Las reglas de asociación se construyen sobre datos que no tenemos etiquetados. Son modelos
descriptivos por lo que no se pueden aplicar las mismas técnicas que en los modelos predictivos.
En el caso de las reglas, se utilizan principalmente las siguientes dos medidas para evaluarlas:
• Cobertura, o soporte de la regla, que es el número de ejemplos sobre los que la regla se
puede aplicar.
• Confianza, o precisión de la regla, que es el porcentaje de veces que la regla se cumple

cuando se puede aplicar.
Por ejemplo, en un conjunto de datos con 100.000 ejemplos donde una regla aplica 55.000 veces
su lado izquierdo y 40.000 veces su lado derecho, tendremos una cobertura del 55% (55.000 veces
de las 100.000) y una confianza del 73% (40.000 veces de entre 55.000).
4.6. Difusión
La fase final de la minería de datos es la de difusión y aplicación de los modelos aprendidos para
poder ser utilizados en la toma de decisiones. Hay que prestar atención a una problemática con
determinados modelos que se consideran opacos --como por ejemplo las redes neuronales o las
máquinas de vectores soporte-- que pueden proporcionar buenos modelos pero que son difíciles
de comprender. Así por ejemplo, una red neuronal aplicada a la determinación del riesgo de un
cliente puede dar buenos resultados, pero no va a permitir explicar por qué ese cliente es de
riesgo. Existen alternativamente métodos explicativos como los árboles de decisión o los métodos
bayesianos, que permiten a partir de un resultado, comprender por qué se ha llegado a él,
facilitando así la creación y difusión del conocimiento. Será quizás por ello que una de las primeras
decisiones a tomar confrontará la explicabilidad del modelo frente a su precisión. Una posible
solución al problema es la de combinar ambos modelos de manera que se aproveche la precisión
obtenida por los modelos opacos, y sobre lo aprendido, se use un modelo más explicativo para
comprender mejor el problema.
Otra cuestión a tener en consideración es la integración de los modelos en los sistemas de

producción para su posterior reutilización. En la mayoría de las ocasiones los modelos se
construyen en suites de minería de datos que proporcionan herramientas para todo el ciclo
completo --descrito en CRISP-DM--. Sin embargo, los sistemas de producción y toma de
decisiones en los que se desee integrar pueden estar escritos en diferentes lenguajes de
programación e incluso en diferentes infraestructuras. Es por ello que se debe considerar la
posibilidad de exportación, difusión e integración de los modelos al margen de la plataforma donde
se crearon. En este sentido, algunos modelos como los árboles de decisión o los métodos
bayesianos son fácilmente programables como conjuntos de reglas o a partir de las probabilidades
calculadas. Sin embargo, la integración de una red neuronal o una máquina de soporte vectorial,
es algo más complicada. En este punto existe un estándar sobre XML denominado PMML
(Predictive Model Markup Language) definido por el Data Mining Group (http://www.dmg.org), que
permite definir y distribuir modelos de minería de datos.
4.7. Herramientas para la minería de datos
Existen multitud de herramientas para la minería de datos, algunas genéricas que permiten definir
el flujo de trabajo y los algoritmos a aplicar, y otras más específicas para realizar tareas concretas.
Debido a su cantidad y proliferación, a continuación hacemos referencia a tres de ellas que
destacan por su potencia y versatilidad, además de ser open source lo que facilita su prueba. Sin
embargo, se recomienda ampliar información sobre otras herramientas como: RapidMiner, SPSS,
dVelox, MicroStrategy, SAS Enterprise Miner, Oracle DataMining, Microsoft SQLServer
Datamining, Teradata Warehouse Miner, AdvancedMiner, Angoss, BayesiaLab, DBMiner, Kepler,
Mathematica for Data Analysis, etcétera.
• Weka (http://www.cs.waikato.ac.nz/ml/weka/) (Witten et al., 2011) es una colección de

algoritmos de aprendizaje desarrollados en Java e integrados a partir de una interfaz
gráfica que permite la lectura, pre-procesado y transformación de los datos, el aprendizaje
de modelos (clasificación, regresión, clustering, reglas de asociación) y su evaluación, así
como visualización (e.g. árboles de decisión). Es software abierto distribuido bajo licencia
GNU General Public License. permite el aprendizaje a partir de grandes volúmenes de
datos (big data) mediante el aprendizaje incremental de los modelos, y en su última versión
(3.8) se proporciona acceso a paquetes de minería de datos distribuida que permiten
aplicar el paradigma MapReduce, o utilizar infraestructuras Hadoop y/o Spark.
• Mahout (https://mahout.apache.org/) (Owen et al., 2011) es un conjunto de librerías Java

para aprendizaje automático, especialmente sistemas de recomendación, clasificación y
clustering. A diferencia de otras herramientas, Mahout es un framework con un conjunto de
librerías que deben ser utilizadas y adaptadas por los desarrolladores. No proporciona
interfaz de usuario, ni servidor pre-configurado, ni un instalador de una suite. Mahout es
software abierto, forma parte del proyecto Apache. Una de sus principales características
es su adecuación al aprendizaje en entornos big data, donde los datos sobre los que
aprender posiblemente no quepan en una sola máquina. Para ello Mahout está integrado
con Hadoop, otro proyecto Apache. Algunos de los ejemplos de aplicaciones conocidas
que utilizan Mahout son Picasa, Google News o Netflix.
• R (https://www.r-project.org/) es tanto un lenguaje como un entorno de desarrollo

especialmente orientado a la computación estadística y la visualización de resultados
gráficos. Como lenguaje, proporciona gran cantidad de métodos de procesamiento
estadístico, como modelado lineal y no lineal, tests estadísticos, análisis de series
temporales, clasificación o clustering. Así mismo, permite la generación de gráficos de
manera sencilla a partir de los datos y los modelos construidos. Además, puesto que es un
lenguaje de programación, permite desarrollar algoritmos propios y compartirlos con la
comunidad, una de las más activas en la actualidad. Como entorno de desarrollo, se
proporciona una suit integrada para trabajar con datos, aplicarles procesos y obtener
salidas visuales. Es destacable la facilidad para trabajar con estructuras de datos como las
matrices, permitiendo aplicar operaciones a todas sus columnas y/o filas sin necesidad de
iterar por ellas. Una de las suites más extendida es R Studio (https://www.rstudio.com/).
5. Arquitecturas y técnicas de procesamiento masivo de

datos (big data)
Big data es un concepto en auge que se ha extendido más allá del ámbito tecnológico,
asociándose a toda una revolución en el mundo de la comunicación, los negocios y el
entretenimiento. Se entiende por big data un conjunto de datos que por su volumen y complejidad
no pueden ser procesados por métodos tradicionales en computadoras tradicionales. Big data es a
su vez un nuevo paradigma donde se coloca al dato como el epicentro organizativo, para lo cual se
obtienen, mezclan y procesan datos fruto de la revolución digital. Datos existentes y que en la
actualidad se mezclan y funden para obtener nuevos datos (balances y cotizaciones de empresas,
datos de consumo, tasas de empleo, precios, natalidad, PIB o clima), con nuevos datos generados
por el internet de las cosas (sensores y dispositivos inteligentes), los wereables (datos vitales, de
hábito y de comportamiento), los dispositivos móviles o las redes sociales (conversaciones, redes
de amistad, fotografías, vídeos, geolocalización, gustos y opiniones).
Una de las principales confusiones a las que lleva el término es a su asociación únicamente con
grandes volúmenes de datos. Sin embargo, al término big data se le asocian una o más de las que
se conocen como las Vs del big data (cuatro o cinco, dependiendo del autor).
• Volumen: Se refiere a cantidades masivas de datos difícilmente almacenables en una sola

máquina o por medios convencionales. Se puede pensar en grandes volúmenes en tareas
de procesamiento de imágenes médicas y/o vídeo digital.
• Velocidad: Se refiere a la velocidad con la que se crean, procesan y/o analizan los datos,
llegando al límite del tiempo real y en base a lo que se conoce como procesamiento en
streaming. Se puede pensar en velocidad al tener que procesar en tiempo real las señales
de múltiples sensores que proporcionen el estado de un paciente, o la recuperación en
tiempo real de redes sociales en un debate presidencial.
• Variedad: Se refiere a la heterogeneidad de los datos que deben ser almacenados,

procesados y/o analizados. Se puede pensar en variedad cuando se debe analizar datos
no estructurados como textos para obtener por ejemplo la demografía de su autor, la
existencia de plagio o la utilización del lenguaje figurado (ironía, sarcasmo).
• Veracidad: Se refiere al nivel de fiabilidad asociado a los datos con los que trabajar. Por
ejemplo, los datos recuperados de redes sociales pueden no ser fiables (por ejemplo,
redes de bots para difamar a un personaje público).
• Valor: Se refiere al potencial valor que se puede obtener de los datos, aunque en
ocasiones puede depender más de la adecuación de las técnicas de minería de datos que
se le apliquen.
A continuación, se va a realizar una revisión de las infraestructuras y técnicas de big data más
utilizadas desde las perspectivas del almacenamiento y el procesamiento.
5.1. Infraestructura de almacenamiento
Tradicionalmente se han utilizado las bases de datos relacionales para almacenamiento y consulta
de la información transaccional de las organizaciones (sistemas OLTP). Sin embargo, con el
crecimiento de las necesidades en los entornos big data, las bases de datos presentan ciertas
limitaciones que no las hacen apropiadas para determinadas tareas. Algunas de estas limitaciones
tienen que ver con su estructura fija y las restricciones de integridad. Cuando se ha desarrollado un
producto, se ha diseñado su modelo de datos y se ha tratado de acomodar la información a
modelar dentro de una estructura fija. Pero en big data ocurre que estos modelos de información
evolucionan a lo largo del tiempo, tanto en la necesidad de incorporar nuevas informaciones a los
datos existentes o incluso variar las reglas de validación de los mismos. Esta heterogeneidad en la
información provoca constantes modificaciones en la estructura de la base de datos relacional,
algo que por un lado puede afectar a su normalización, perdiendo así una de sus principales
características, y que por otro lado y quizás más impactante, a su rendimiento, ya que cuando se
intenta añadir, modificar o borrar grandes volúmenes de información, las bases de datos
relacionales no son muy efectivas.
En relación a esto último, otra de las grandes limitaciones de las bases de datos relacionales es su
rendimiento en inserción de datos. Debido precisamente a las comprobaciones necesarias para
asegurar su estructura y sus restricciones, las bases de datos relacionales no están optimizadas
para la inserción masiva de datos (e.g. decenas de miles de inserciones por segundo). Si
recordamos las fuentes de información, encontramos que algunas de ellas generan volúmenes de
datos asombrosos casi de manera constante en el tiempo (e.g. señales de sensores,
conversaciones en redes sociales…). Esto implica efectuar inserciones de grandes volúmenes a
gran velocidad, algo que pronto deteriora el rendimiento de estas bases de datos.
Otro aspecto importante y que limita la capacidad de uso de las bases de datos relacionales en
entornos big data tiene que ver con una limitación en el significado de su propio nombre. Pese a
que las bases de datos relacionales se llaman así por permitir la relación entre datos, a partir de
las claves primarias y foráneas que permiten relacionar unas tablas con otras, las bases de datos
relacionales permiten trabajar con relaciones existentes en el mundo real de una manera muy
limitada. Esto es así porque las relaciones que se permiten están muy ligadas a su diseño,
propiciando que ciertas consultas sean sencillas de hacer, pero otras lleguen a ser muy costosas,
a la par que complican el diseño de la base de datos mezclando tablas que modelan el mundo real
(e.g. personas, pedidos, productos), y tablas que modelan las relaciones n a n (e.g. líneas de
pedido relacionando producto con pedido y con persona). Esta meta-información necesaria para el
correcto funcionamiento del modelo añade complejidad computacional al sistema, aún más cuando
se producen relaciones nulas entre elementos (e.g. inner/left/right joins, in selects…). Pero el
mayor problema aparece cuando se desea tratar con relaciones más complejas y para las que no
se ha modelado explícitamente el sistema, como por ejemplo cuando se desea contestar a
preguntas como “¿qué clientes han comprado un producto?”, o cuando entramos en dominios
altamente conectados. Veamos un simple ejemplo, las relaciones de amistad de Twitter, donde la
amistad no es recíproca y considerar a alguien tu amigo no implica que él te considere amigo a ti
(redes seguido/seguidor).
Debido a estos y otros problemas con las bases de datos relacionales, se ha evolucionado a
sistemas que se conocen como bases de datos NoSQL, no por negar el uso de SQL, sino porque
son algo más que SQL (Not Only SQL). Estas bases de datos NoSQL tienen por principal misión
ser capaces de almacenar grandes volúmenes de datos desestructurados en pequeñas unidades
de tiempo. Es decir, priman la inexistencia de reglas y restricciones, permitiendo insertar en
cualquier momento cualquier tipo de información, quizás en una estrategia perezosa que permita
adaptarse al dominio a posteriori, agilizando y primando la inserción masiva de datos frente a su
consulta.
Existe gran variedad de bases de datos NoSQL, aunque por su mayor penetración en entornos big
data (e.g. en empresas como Google, Facebook o Twitter), vamos a considerar los siguientes
cuatro tipos: orientadas a documentos, almacenes clave/valor u organizadas por filas, organizadas
por columnas y basadas en grafos.
5.1.1. Bases de datos orientadas a documentos
La unidad básica de almacenamiento en una base de datos orientada a documentos es el

documento. Un documento puede contener cualquier número arbitrario de campos de cualquier
tamaño y tipo, y puede almacenar múltiples valores. Un ejemplo de documento sería un objeto
JSON o un objeto XML.
Las bases de datos orientadas a documentos no requieren de un esquema fijo de documento,

flexibilizando así el modelado de objetos del mundo real. Si necesitamos crear un nuevo
documento, éste podrá contener distintos campos al anterior. Una ventaja que proporciona este
modelo es que para aquellos campos para los que no se disponga información (e.g. una persona
para la que no tenemos el correo electrónico), no es necesario almacenar un valor vacío o un nulo,
reduciendo de manera considerable el espacio de almacenamiento necesario.
La seguridad en este tipo de bases de datos se asigna a nivel de documento individual,

proporcionando mayor control sobre los accesos al mismo. De manera similar, se proporciona la
capacidad de búsqueda por texto completo de manera eficiente, algo que en las bases de datos
relacionales puede resultar prohibitivo. Algunos ejemplos de bases de datos de este tipo son las
siguientes:
• IBM Lotus: siendo su primera versión de 1989, es una de las pioneras y fuente de
inspiración para otras bases de datos orientadas a documentos como las que se describen
a continuación. El modelo de documento es propietario y no necesita esquema. Los
documentos, conocidos como notas, se almacenan en un formato nativo llamado Notes
Storage File (NFS). Se integra en toda una suite de herramientas (Lotus Notes, Lotus
Domino, etc.) y se puede acceder mediante APIs construidas en C, C++ y Java.
• Apache CouchDB: nace entre 2005 y 2008 con el objetivo de ser la base de datos de la
web. Su iniciador trabajó previamente para IBM en el proyecto Lotus Notes, por lo que
tienen ciertas similitudes, como la no necesidad de disponer de un esquema de datos. El
formato de documentos es JSON y se puede acceder a los datos mediante una API
RESTful vía peticiones HTTP. Una característica interesante es que soporta MapReduce.
• MongoDB: es quizás la base de datos orientada a documentos más conocida y usada en

la actualidad, propiciado por características como ser open source, ser sencilla de instalar
y mantener, o proporcionar soporte para MapReduce. MongoDB almacena los documentos
en formato JSON, aunque permite la utilización de esquemas dinámicos, así como
combina capacidades de almacenamiento clave/valor, base de datos orientada a objetos o
base de datos relacional. Es utilizada por SourceForge, Bit.ly, Foursquare o GitHub, entre
otros.
5.1.2. Almacenes clave/valor
A diferencia de las bases de datos relacionales, donde se define un esquema para modelar el
dominio de información que se desea almacenar, con restricciones y normalizaciones, en los
almacenes clave/valor no se especifica nada de lo anterior. Simplemente se convierten en
espacios donde almacenar cualquier información y de cualquier tipo, identificados por una clave y
una serie de atributos. Así pues, cualquier objeto que se desee almacenar en un modelo
clave/valor únicamente debe ser identificado por una clave y una serie de atributos que lo definan.
Al no existir estructura previa ni restricciones, por ejemplo, un objeto tipo persona podrá
almacenarse con unos atributos diferentes a otro objeto de tipo persona, y en ambos casos será la
clave seleccionada la que identifique y haga accesible al objeto. Es por ello que se denominan
también almacenes hash distribuidos, ya que como una función hash, a partir de una clave se
obtiene un valor como por ejemplo el conjunto de atributos que definen al objeto. Algunos
almacenes clave/valor son los siguientes:
• Dynamo DB: Nacida para dar soporte a las tiendas Amazon como base de datos escalable
y de alto rendimiento, en la actualidad se ofrece como servicio a los clientes de Amazon
Web Services (AWS). Dynamo es base de otras tecnologías como las siguientes.
• Riak: Es una base de datos híbrida clave/valor y por columnas basada en Amazon
Dynamo y desarrollada por Basho. Por otro lado, su sistema de tolerancia a fallos funciona
de manera similar a Cassandra. Los datos se almacenan en buckets en parejas
clave/valor, lo que la asemeja al sistema Google Storage. Se proporciona tanto licencia
comercial como open source.
• Voldermort: Proyecto de LinkedIn que se basa tanto en Dynamo como en Memcached,

uno de sus principales objetivos es cubrir la alta demanda de lecturas y escrituras de una
red social como LinkedIn. Voldemort permite definir esquemas clave-valor con los mismos
tipos que permite JSON, lenguaje con el que se especifican. Se integra con Thrift, Avro y
GPB (Google Protocol Buffers).
Otros almacenes clave-valor son Memcached, Membase y Redis.
5.1.3. Bases de datos organizadas por columnas
Son bases de datos que se organizan en torno a tablas con familias de columnas predefinidas. Los
datos pues se organizan en torno a columnas en lugar de en torno a filas. Esto propicia ciertas
operaciones como las de agregar datos, tan utilizadas en los almacenes de datos orientados a
OLAP. Ejemplos de bases de datos de este tipo tenemos:
• Google Big Table (Chang et al., 2008): Es una base de datos de uso interno por Google
con el principal objetivo de poder tratar con grandes volúmenes de datos (del orden del
Petabyte) de manera escalable y tolerante a fallos. Se construye sobre el sistema de
ficheros de Google File System (GFS) y soporta gran parte de los proyectos de Google
como Gmail, Youtube, Analytics, Earth o el propio buscador.
• HBASE: Es un clon de Google Big Table pensado para ser integrado con Hadoop y poder
aplicar procesos MapReduce. Una de sus principales diferencias con el resto de bases de
datos orientadas a columnas es que asegura la consistencia de manera completa.
• Cassandra: Es un proyecto open source de Apache para construir una base de datos
distribuida, descentralizada, elástica, escalable, de alta disponibilidad, tolerante a fallos,
personalizable y consistente que se ha diseñado sobre el modelo Amazon Dynamo en
cuanto a consistencia y tolerancia se refiere, pero el modelo de datos se toma de Google
Bigtable (Hewitt, 2011).
Otras bases de datos organizadas por columnas son Sybase IQ o Hypertable.
5.1.4. Bases de datos basadas en grafos
Las bases de datos NoSQL anteriores permiten la inserción masiva de datos no estructurados y su
rápida recuperación en base a claves únicas que identifican la información. Sin embargo, este tipo
de bases de datos sigue adoleciendo de problemas para manejar relaciones. Por ejemplo,
partiendo del modelo de compras de una empresa donde tenemos personas que efectúan pedidos
y que dichos pedidos incorporan productos, en un modelo de base de datos clave valor tendríamos
las siguientes tres conjuntos de datos: personas, pedidos y productos. Mediante la agregación de
campos de relación a cada uno de esos tres conjuntos podemos indicar cuál es la lista de pedidos
que realiza una persona y cuál es la lista de productos que incorpora cada pedido. La principal
desventaja de este modelo es que se tiene que asegurar por software el mantenimiento de estas
relaciones, añadiendo, modificando o eliminando cualquier nueva circunstancia. Esto, complica el
desarrollo.
Pero el principal problema viene cuando queremos responder a la pregunta que planteábamos con
la base de datos relacional: ¿qué personas han comprado determinado producto? Puesto que este
modelo no dispone de relación, simplemente la hemos emulado mediante los enlaces agregados, y
dichos enlaces no tienen una relación hacia atrás, esta pregunta no podemos contestarla sin
recorrer por software toda la base de datos buscando y memorizando las personas que compraron
dicho producto, o bien añadiendo otro campo agregado hacia atrás que almacene cada producto,
por el pedido en el que ha sido incorporado, por qué persona ha sido comprando, teniendo así en
cada producto una lista de personas que lo compraron. Esto es tremendamente costoso y complejo
de manejar a nivel de software y nos hace plantearnos si no estamos simulando con NoSQL lo que
ya nos proporcionaba el SQL.
En este punto es donde las bases de datos basadas en grafo aportan su valor, ya que almacenan
inherentemente no sólo la información de los elementos del modelo (e.g. personas, pedidos,
productos), sino también la información de las relaciones entre ellos (e.g. amigo de, pide, incluye,
es_pedido, es_incluido), lo que va a permitir no sólo consultar sobre un elemento (base de datos
NoSQL clave/valor), o una relación simple de primer nivel (base de datos relacional), sino también
sobre la propia estructura de la red (operaciones sobre el grafo). Para ello, una base de datos
basada en grafos debe permitir modelar la realidad en función de los siguientes elementos: nodos,
relaciones y propiedades.
• Nodos, que representan entidades del mundo real (e.g. personas, pedidos, productos,
ciudades, computadores, direcciones físicas, etcétera), y que pueden contener
propiedades, generalmente representadas por parejas clave/valor (e.g. una persona tiene
nombre, teléfono y DNI; una computadora tiene una dirección IP y un sistema operativo).
• Relaciones, que conectan a los nodos entre sí y dotan de estructura a la red. Una relación
siempre tendrá un nodo de origen y un nodo destino (e.g. una persona es amiga de otra
persona; una carretera lleva de una dirección a otra), y puede ser dirigido (e.g. que yo te
considere mi amigo no implica lo contrario; una calle de un sentido lleva de una dirección a
otra, pero no al revés) o no dirigido/bidireccional (e.g. si eres hermano de alguien ese
alguien es también tu hermano; dos ordenadores conectados al mismo hub). Las
relaciones también pueden tener propiedades que las especifiquen. Por ejemplo, el peso
de una relación de amistad (muy amigo, amigo, conocido), o el peso de una línea de
transmisión.
Una representación basada en grafos implica que las relaciones forman caminos entre las
entidades, y la consulta al grafo implica consultar dichos caminos. Quién es amigo de quién, quién
ha comprado qué, qué ha sido comprado por quién, cuántos saltos hay de un nodo a otro, son
algunos de los ejemplos de consulta que se nos ocurren al visualizar un grafo. Por lo tanto, la
consulta a una base de datos de este tipo se convierte en la búsqueda de caminos entre nodos.
Para ello, se han propuesto lenguajes de consulta como Cypher, que se basa en consultar la base
de datos mediante la búsqueda de concordancia entre patrones (e.g. encuentra algo como esto).
Esto es lo que se conoce la especificación por ejemplo. Se sugiere la realización de los tutoriales
en línea de Neo4J y la bibliografía propuesta, para profundizar en bases de datos basadas en
grafos y su consulta mediante Cypher.
Ejemplos de bases de datos basadas en grafos están FlockDB, OrientDB, AllegroGraph y Neo4J,
entre otras. Destaca sin embargo la última:
• Neo4J es una base de datos de grafos desarrollada en Java por Neo Technology. Dispone
de una versión comercial y de una versión bajo licencia AGPL V3. Es un motor de
persistencia embebido, basado en disco, y es completamente transaccional. Los datos se
almacenan en forma de grafos de manera nativa.
5.1.5. Resumen de tecnologías
Tabla V: Ejemplo de predicciones. Fuente: Elaboración propia
DOCUMENTOS CLAVE/VALOR COLUMNAS GRAFOS

Riak Google Bigtable FlockDB
Voldemort HBase OrientDB
MongoDB
Redis Cassandra AllegroGraph
CouchDB
Memcached Sybase IQ Neo4J
Riak
Membase Hypertable
DynamoDB
5.2. Infraestructura de procesamiento
En la introducción a big data se mostraron las diferentes Vs que definen el concepto. Desde la
perspectiva del procesamiento tenemos dos posibles aproximaciones, dependiendo de la V
dominante, y una aproximación híbrida.
Figura 5: Procesamiento batch vs. streaming vs. híbrido. Fuente: Elaboración propia
• Procesamiento batch: Su principal orientación es hacia el procesamiento de grandes

volúmenes de datos estáticos de manera escalable. Sin embargo, no es importante que se
produzca una elevada latencia en el procesamiento.
• Procesamiento streaming: Su principal orientación es hacia el procesamiento de un flujo

continuo de datos, donde prima la velocidad. Son sistemas donde se debe asegurar una
baja latencia.
• Procesamiento híbrido: El objeto es procesar grandes volúmenes en tiempo real, por lo

que deben asegurar baja latencia y escalabilidad. Su infraestructura suele ser híbrida, con
un sistema batch para los grandes volúmenes y un sistema streaming para los datos
continuos, combinando los resultados a la salida. Este tipo de sistemas es el que más
complejidad inherente presenta.
En entornos big data el flujo de procesamiento se divide en tres fases: adquisición de los datos,
almacenamiento y análisis.
• Adquisición de datos: En el apartado de minería de datos vimos en qué consistía la

creación y rellenado de un almacén de datos, así como las tareas de preparación de los
datos y construcción de características. En esta fase se preparan los datos para ser
distribuidos a la infraestructura de procesamiento.
• Almacenamiento de datos: En esta fase los datos se distribuyen y almacenan de manera

local (incluso in-memory) en los diferentes nodos de la infraestructura de procesamiento
para que estén disponibles para su procesado. Es lo que se denomina llevar el dato al
proceso, a diferencia de los paradigmas clásicos donde la aplicación iba a buscar al dato.
• Análisis de datos: Es la última fase del proceso y consiste en aplicar los algoritmos y
técnicas necesarios, algunos de ellos de minería de datos, para obtener los resultados
esperados.
Existen tecnologías y modelos de procesamiento específicos para cada una de estas fases
dependiendo de si se requiere procesamiento batch o en streaming. A continuación hacemos un
repaso de algunas de las tecnologías en boga en cada una de las fases dependiendo del tipo de
procesamiento, así como de los paradigmas que hay tras ellas.
5.2.1. Procesamiento en batch
El procesamiento en batch es el que se realiza sobre grandes volúmenes de datos, sin importar en
exceso la latencia, pero asegurando la escalabilidad. Ello va a implicar mover grandes volúmenes
de datos y distribuirlos entre diferentes nodos para procesarlos de manera escalable. Por claridad
de conceptos, presentaremos las tecnologías siguiendo el orden almacenamiento, adquisición y
análisis.
5.2.1.1. Fase de almacenamiento de datos
Principalmente son dos las tecnologías utilizadas para almacenamiento de los datos en
procesamiento batch: HDFS y HBase.
HDFS o Hadoop Distributed File System es el sistema de ficheros proporcionado por Hadoop para
distribuir los datos entre sus nodos de procesamiento. HDFS es una arquitectura master-slave,
donde el maestro gestiona el acceso a la información, así como su estructura en directorios, y los
esclavos contienen los datos. Por ello, al maestro se le conoce como el NameNode y a los
esclavos los DataNodes.
Como vimos en el apartado de almacenamiento, HBase es una base de datos NoSQL distribuida
orientada a columnas. HBase proporciona acceso aleatorio al dato en tiempo real tanto en lectura
como en escritura.
5.2.1.2. Fase de adquisición de datos
Como se verá en los siguientes apartados, Hadoop y su sistema de ficheros HDFS es uno de los
más utilizados por diferentes tecnologías para almacenar los datos de manera distribuida y
acercarlos a los diferentes nodos de proceso. Así pues, una de las primeras herramientas las
proporciona el propio HDFS a modo de comandos que permiten distribuir desde un nodo local la
información a los nodos remotos.
hadoop dfs -copyFromLocal <ruta-local> <ruta-remota>
Ruta local suele ser un directorio en el sistema local y la ruta remota un directorio en el sistema
HDFS. Pero en ocasiones los datos se encuentran almacenados en bases de datos SQL, y es
Sqoop la tecnología que permite mover dichos datos entre las bases de datos relacionales (tiene
conectores para la mayoría de ellas), y los sistemas de almacenamiento HDFS y HBase. Funciona
a partir de comandos como los siguientes:
import --connect [cadena de conexión a bbdd] --target-dir [ruta hdfs] [opciones]
export --connect [cadena de conexión a bbdd] --target_dir [ruta hdfs] [opciones]
Donde la primera mueve los datos de una base de datos relacional al sistema HDFS y la segunda
mueve los datos de HDFS a la base de datos relacional. En opciones se indican la tabla o tablas
que se desean exportar, así como las credenciales del usuario.
Una de las fuentes de información que más volumen genera y que en ocasiones es preciso
analizar son los logs de los procesos. Para ello, Flume proporciona herramientas para mover datos
de este tipo desde fuentes como Avro, Syslog, NetCat o cualquier fuente personalizada hacia
ficheros, memoria o bases de datos.
5.2.1.3. Fase de análisis de datos
MapReduce es el paradigma y framework de procesamiento distribuido de datos más extendido y

conocido. Su filosofía se inspira en el clásico Divide y Vencerás, para lo que descompone los datos
de origen en diferentes subconjuntos (Map) para que los procesen los nodos, y el resultado se
retorna para realizar una combinación de los resultados (Reduce). Concretamente:
• Map: El proceso Map divide los datos en subconjuntos y los envía a cada nodo de proceso
en formato clave-valor <K, V>.
• Reduce: Cada nodo retorna el resultado en formato clave-lista de valores <K, L(V)> y se
combinan produciendo el resultado final.
Un ejemplo clásico para entender MapReduce es el conteo de palabras de un texto, que se adapta
perfectamente a dicho paradigma. En el proceso Map, se enviará a cada nodo una línea del texto,
donde la clave K será el número de línea, y el valor V será la línea de texto <nºlínea, texto>. El
resultado de la tarea será una lista de parejas <palabra, 1> para cada palabra del texto. El
pseudocódigo del proceso Map sería:
Map (clave, valor) {
Para cada palabra w en valor:
retornar (palabra, 1)
}
El proceso Reduce recogerá todas las salidas de los procesos Map como parejas <clave, valor> o
<palabra, 1>, y se encargará de agruparlas en parejas <palabra, ocurrencia> mediante la suma de
unos de cada palabra. En pseudocódigo el proceso Reduce sería:
Reduce (palabra, lista_de_valores) {
Para cada valor v en lista_de_valores:
total += v
Retornar (palabra, total)
}
La potencia de MapReduce está en su filosofía Divide y Vencerás, pero la primera vez que un
programador se enfrenta a él, pese a su sencillez conceptual, le resulta complejo. Es por ello que
se han desarrollado tecnologías que proporcionan capacidades MapReduce pero con una capa de
abstracción por encima. De entre ellas destacan Hive, Pig y Cascading:
• Hive: No sólo es una capa de abstracción de MapReduce sino que además proporciona
todo el sistema de almacén de datos completo junto con la posibilidad de ejecutar
consultas sobre grandes volúmenes de datos. Hive proporciona una versión adaptada de
SQL (HiveSQL) para acceder de manera similar a los datos.
• Pig: Es una plataforma para analizar grandes volúmenes de datos a partir de una
especificación de flujo de datos en lenguaje de alto nivel (Data flow programming
language).
• Cascading: Es una plataforma que permite la creación de flujos MapReduce complejos de

manera sencilla mediante un planificador de procesos de consulta.
Aunque quizás el sistema de computación distribuida que está tomando un papel más relevante es
Spark. Spark no es una versión de Hadoop, aunque es compatible con su sistema de ficheros
HDFS y funciona de manera similar, permitiendo el desarrollo de flujos MapReduce escritos en
lenguajes Java, Python o Scala. Además de ser más sencillo que Hadoop, entre otras cosas por
permitir utilizar su propio lenguaje Scala, o lenguajes con los que el desarrollador esté familiarizado
como Python o Java, se argumenta que la ejecución es más rápida que en Hadoop, quizás por
mantener los datos en memoria. Esto sin embargo hace que las necesidades de memoria sean
superiores a su equivalente en Hadoop. Al igual que Hive, Spark proporciona un almacén de datos
y una capa de abstracción denominada SparkQL que permite acceder a los datos utilizando una
variación del lenguaje de consulta SQL.
5.2.2. Procesamiento en streaming
El procesamiento en streaming no tiene por qué involucrar grandes volúmenes de datos, pero sí
una necesidad de consumirlos en tiempo real.
5.2.2.1. Fase de almacenamiento de datos
Los almacenes de datos deben propiciar unos tiempos de respuesta y unas latencias bajas, no
sólo al momento de consultar el dato, sino especialmente al momento de su inserción, puesto que
pueden ser múltiples y desde muchos sitios diferentes. En este sentido, los almacenes de datos
suelen actuar a modo de colas donde diferentes agentes producen datos mientras que otra serie
de agentes los consumen, creando así un flujo continuo de datos. En este sentido destaca la
tecnología Kafka. Kafka es un sistema de colas distribuido que permite el trabajo en el modelo
productor/consumidor. En este modelo, múltiples productores de datos insertan en las colas los
datos que múltiples consumidores recuperarán para efectuar su procesamiento. Un ejemplo se
puede ver en la parte superior de la Figura 6.
En ella se muestran múltiples procesos de recuperación de datos del streaming API de Twitter
(Twitter Stream y Process Local Stream), que almacenan el resultado en disco local y lanzan
trabajos a las colas de proceso (Massive Queue, Real Time Queue y Specific Queue). Múltiples
procesos de análisis (Process Remote Stream) se encargan de recuperar el dato y efectuar su
procesamiento, enviando el resultado a la siguiente etapa (Indexer), y de ahí a la siguiente
(Neo4J). Ejemplo del análisis realizado, extracción de sentimiento, extractor de tópicos, de
topónimos, de nombres propios (NER), construcción de redes y análisis de comunidades,
influencia e intermediación (SNA), identificación de datos demográficos de los usuarios (autor
profiling), y un largo etcétera.
Figura 6: Arquitectura Cosmos Intelligence de Autoritas. Fuente: Elaboración propia
Otras tecnologías basadas en colas son Kestrel, RabbitMQ o SQS de Amazon AWS.
5.2.2.2. Fase de adquisición de datos
La adquisición de datos en tiempo real dependerá del servicio o fuente de datos de la cual se
dependa. Así por ejemplo, la mayoría de servicios de red social actuales permiten recuperar
información de su plataforma, aunque sólo algunos lo permiten en streaming. Un ejemplo de este
tipo sería la Streaming API de Twitter, o incluso su Firehose. Para extraer datos en tiempo real se
debe conectar un proceso directamente a dicha API y procesar toda la información que se genera.
En este sentido, se pueden desarrollar pequeñas aplicaciones siguiendo las indicaciones de los
manuales de las propias APIs. Sin embargo, de manera más general, puede interesar la utilización
de tecnologías de adquisición de datos, como pueda ser Flume. Flume es un servicio de
recolección, agregación y transmisión de datos en tiempo real que permite conectarse a un flujo de
datos, transformarlo y almacenarlo, por ejemplo, en un sistema de ficheros HDFS o en una cola
Kafka.
5.2.2.3. Fase de análisis de datos
A la hora de analizar los datos que nos llegan en streaming, puede resultar interesante utilizar
parte de la tecnología utilizada para capturarlos. Este es el caso de Flume, que además de permitir
conectarse con diversas fuentes de datos y recuperar en tiempo real, permite conectar
interceptores a los datos de entrada, a modo de eventos, que lancen la lógica de análisis
implementada.
Algo más avanzado lo proporciona Storm, que es un sistema de procesamiento en tiempo real
escalable y distribuido. Storm permite realizar para el real time lo que Hadoop permite en los
procesos batch. Una de las ventajas de Storm es que permite utilizar cualquier lenguaje de
programación, reduciendo el tiempo de aprendizaje, y además se integra con múltiples tecnologías
de base de datos distribuidas y sistemas de encolado. Storm se organiza mediante una topología
en forma de grafo. Cada nodo contiene la lógica de aplicación. Existen nodos spout que se
conectan a las fuentes de datos streaming y emiten los datos hacia la topología. Los nodos bolts
son las unidades de procesamiento, que leen datos de otros nodos y emiten datos hacia otros
nodos. De este modo se puede construir la topología necesaria para aproximar el problema.
Son diferentes las tecnologías que se han desarrollado sobre Storm con el objetivo de abstraer su
implementación y simplificar su uso. En este sentido destaca Trident, que se basa en pequeños
procesos batch que implementan operaciones de alto nivel como joins, filtros, proyecciones,
agregaciones o diferentes tipos de funciones, y se enlazan para conseguir el flujo de proceso
deseado. Sin embargo, su principal limitación es la necesidad de adaptarse a estas funciones, por
lo que Storm es más potente.
De nuevo Spark destaca por aportar su versión Spark Streaming, para procesamiento en tiempo
real. Su funcionamiento es similar a Spark, con pequeños batch que se concatenan para conseguir
el flujo de procesamiento deseado, y que se almacenan en memoria para mejorar el rendimiento, a
costa de una mayor necesidad de espacio.
Existen otras tecnologías que proporcionan capacidades de análisis en streaming o tiempo real
como son S4 (Simple Scalable Streaming System) utilizado por Yahoo! o Samza, desarrollado por
LinkedIn, que con una perfecta conexión con Kafka --también utilizado por LinkedIn-- permite una
integración completa del proceso con la adquisición de datos vía Flume.
5.2.3. Procesamiento híbrido
Aunque el procesamiento híbrido está en su infancia, cada vez más las necesidades se dirigen
hacia esta línea. Así, una de las primeras arquitecturas definidas es la conocida como Lambda.
Lambda es una arquitectura genérica para procesamiento distribuido que sea escalable, tolerante a
fallos y con una baja latencia. La siguiente imagen muestra la arquitectura Lambda:
Figura 7: Arquitectura Lambda. Fuente: Lambda Architecture
En ella se aprecia cómo todos los datos que llegan al sistema [1] se envían tanto a la capa batch
[2] como a la capa speed [4]. La capa batch se encarga de almacenar los datos en bruto y de
prepararlos para la visualización, mientras que la capa serving [3] se encarga de generar los
índices para obtener baja latencia en las consultas. La capa speed reduce la latencia dando
acceso únicamente a los datos más recientes. Cuando se produce una consulta por parte del
usuario [5], esta se lanza a ambas capas, consiguiéndose una baja latencia por servir primero los
datos más recientes de la capa speed, y posteriormente los ya procesados e indexados en la capa
serving. Esta arquitectura es utilizada por el motor de búsqueda de Twitter.
La arquitectura Kappa por su parte es una simplificación de la Lambda en la cual se ha eliminado

la capa batch. En Kappa los datos se envían directamente a través del sistema speed (streaming)
a modo de un nuevo flujo de información en un registro inmutable de información que sólo se
añade.
Teniendo en consideración las arquitecturas anteriores, se han desarrollado tecnologías que

permiten aprovechar las tecnologías existentes tanto para procesamiento batch como en
streaming, y construir arquitecturas híbridas de proceso. Una de las tecnologías que destaca es
Lambdoop, que es una capa de abstracción de prácticamente todas las tecnologías vistas hasta
ahora: Kafka, Flume, Hadoop, Spark/Spark Streaming y Storm, entre otras.
Otra capa de abstracción sobre arquitectura Lambda es Sumingbird, utilizada por Twitter, que
permite escribir procesos escritos en Scala en un formato similar a MapReduce, y ejecutarlos sobre
Hadoop para procesos batch, sobre Storm para procesos stream, o sobre ambos de manera
híbrida.
El proyecto Flink proporciona una implementación de la arquitectura Kappa que únicamente

permite realizar procesamiento en streaming. El procesamiento batch se debe realizar como si de
un proceso en streaming se tratara, simplificando de este modo la implementación.
5.2.4. Resumen de tecnologías
Tabla VI: Resumen de tecnologías de procesamiento big data. Fuente: Elaboración propia
ADQUISICIÓN ALMACENAMIENTO ANÁLISIS

HDFS MapReduce
Comandos HDFS HBase Spark, SparkQL
BATCH Sqoop Hive
Flume Pig
Cascading
Kafka Storm
Kestrel Trident
STREAMING Flume
RabbitMQ Spark Streaming
AWS SQS Samza
HÍBRIDO Lambda, Kappa, Summingbird, Lambdoop, Apache Flink
Referencias
(1) Aggargal, C. C. (2011). Social network data analytics. Springer.
(2) Aguilar, F. (1967). Scanning the business environment. New York, Macmillan.
(3) Alag, S. (2009). Collective intelligence in action. Manning Publications.
(4) Arjonilla Domínguez, S. J., & Medina Garrido, J. A. (2002). La gestión de los sistemas de
información en la empresa. Colección Economía y empresa/Pirámide.
(5) Banker, K. (2012). Mongodb in action. Manning Publications.
(6) Bradley, S.P., Hausman, J.A., Nolan, R.L. (1993). Globalization, technology and competition.
The fusion of computers and telecommunications in the 1990’s. Harvard Business School.
(7) Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D.A., Burrows, M., Chandra, T.,
Fikes, A., Gruber, R. E. (2008). Bigtable: a distributed storage system for structured data.
ACM Transactions on Computer Systems.
(8) Clark, P., Boswell, R. (2000). Data mining. Practical machine learning tools and techniques with
java implementations. Morgan Kaufmann Publishers.
(9) Dixon, J. (2015). Pentaho, hadoop and data lakes. James Dixon’s Blog.
(10) Harrington, P. (2012). Machine learning in action. Manning Publications.
(11) Hashem, I. A. T., Yaqoob, I., Anuar, N. B., Mokhtar, S., Gani, A., & Khan, S. U. (2015). The
rise of “big data” on cloud computing: Review and open research issues. Information
Systems.
(12) Hayes, R., Wheelright, S. (1985). Restoring our competitive edge: competing through
manufacturing. John Whiley & Sons.
(13) Hernández-Orallo, J., Ramírez-Quintana, M. J., Ferri-Ramírez, C. (2004). Introducción a la

minería de datos. Pearson Educación. Prentice Hall.
(14) Hewitt, E. (2011). Cassandra: the definitive guide. O’Reilly.
(15) Inose, H, Pierce, J.H. (1984). Information technology and civilization. W.H. Freeman and
Company.
(16) Jones, O. M., Robinson, A. (2009). Scientific programming and simulation using r. Taylor &
Francis Group.
(17) Koller, T. (1994). What is value-based management? The McKinsey Quarterly.
(18) Lam, C. (2011). Hadoop in action. Manning Publications.
(19) Leskovec, J., Rajaraman, A., Ullman, J. D. (2014). Mining of massive datasets. Stanford
University Press.
(20) Marmanis, H., Babenko, D. (2009). Algorithms of the intelligent web. Manning Publications.
(21) Mateos, P. (2005) Dirección y objetivos de la empresa actual. Editorial Centro de Estudios
Ramón Areces.
(22) Mitchel, T. M. (1986). Machine learning. Springer.
(23) Moore, G. E. (1965). Cramming more components onto integrated circuits. Electronics
Magazine.
(24) Owen, S., Anil, R., Dunning, T., Friedman, E. (2013). Mahout in action. Manning Publications
Co.
(25) Porter, M.E. (1979). How competitive forces shape strategy. Harvard Business Review Boston.
(26) Robinson, I., Webber, J., Eifrem, E. (2013). Graph databases. O’Reilly.
(27) Snijders, C.; Matzat, U.; Reips, U.D. (2012). Big data: big gaps of knowledge in the field of
interent. International Journal of Internet Science.
(28) Stanton, J. (2012). An introduction to data science. Syracuse University.
(29) Witten, I. H., Frank, E., Hall, M. A. (2011). Data mining. Practical machine learning tools and
techniques. Morgan Kaufmann Publishers.
Enlaces web:
Big Data y Social Media en retrospectiva. Blog Francisco Rangel (2015):

http://www.kicorangel.com/big-data-y-social-media-en-retrospectiva/
Cosmos Intelligence: http://www.autoritas.net/#section-herramienta
El análisis masivo de datos está transformando a la empresa. John Veihmeyer (2015):

http://economia.elpais.com/economia/2015/01/22/actualidad/1421926110_795741.html
Tema 37. Diseño y desarrollo de portales web.
Lenguajes y herramientas para la utilización de
redes globales. HTML y XML

Colegiado 0879
Hoy en día, los documentos HTML son los más abundantes del mundo digital. Se
desarrollan todo tipo de aplicaciones web, estáticas aunque casi en su totalidad
dinámicas; y con indefinidas funcionalidades: blog, comercio electrónico, de
descargas, de desarrollo, institucionales, comunidades virtuales, directorios,
informativas, redes sociales, personales, wikis, educativas, juegos, etc.
Los documentos HTML, cuyos orígenes se remontan a principio de los noventa, y que
actualmente se encuentra en su versión HTML5, permiten incorporar contenido similar
a los procesadores de texto actuales, aunque sobre todo, permiten la interactuación
por parte del usuario, mediante enlaces, pudiendo acceder entre documentos, gracias
al hipertexto.
El lenguaje HTML es sin duda el más empleado para implementar aplicaciones web,
pero trabaja de la mano de CSS y JavaScript para explotar al máximo sus
posibilidades. HTML por sí sólo es capaz de organizar la información, mientras las
hojas de estilos CSS aportan el diseño para hacer que los documentos sean mucho
más atractivos. Paralelamente, JavaScript dota a HTML de una serie de
funcionalidades extra para permitir programaciones en el lado del cliente. Y para que
el diseño no llegue a dificultar el acceso a la documento, se han desarrollado
estándares de accesibilidad, que aseguran sobre todo el acceso a la información a
personas con discapacidades de cualquier índole.
1. Lenguajes de marcas
1.1. Principios
Los lenguajes de marcas o de marcado definen la estructura, la semántica y controlan el

procesamiento de un documento digital. Los lenguajes de descripción de páginas (archivos
PostScript, PDF, etc.) y los lenguajes de programación (Java, Basic, Perl, C++, ect.) no son
lenguajes de marcas.
En un documento existen distintos niveles de información, por un lado la información del contenido
del documento y por otro la información del etiquetado, marcado o markup.
Los lenguajes de marcas aparecieron ante la problemática de intercambio de información con

pérdidas de formato y otras características. Para resolver el problema, se acordó que las marcas
deberían constar de caracteres ASCII reservados y se deberían cumplir una serie de reglas
sintácticas especiales. Ello provocó el nacimiento de un lenguaje especial normalizado
internacional para la formulación de este tipo de reglas denominado Standard
GeneralizedMarkupLanguage o SGML.
La aceptación de SGML fue muy grande y es empleado en una gran cantidad de campos en los
que se requiere documentación a gran escala. Y ello a pesar de que inicialmente los procesadores
de textos, decidieron optar por editores WYSIWYG en lugar de emplear lenguajes de marcado.
Otro de los puntos clave para que tenga la relevancia actual, fue la aparición del HTML utilizando
la sintaxis SGML. La sencillez del lenguaje fue uno de los principales factores junto a las ventajas
que el propio lenguaje ofrece. También existía el problema de la mala estructuración de la
información y la falta de respeto por los estándares por diseñadores y fabricantes de software.
La respuesta a los problemas del HTML vino de la mano del XML (eXtensibleMarkupLanguage),
desarrollado por el World Wide Web Consortium (W3C), meta-lenguaje que permite crear etiquetas
adaptadas a las necesidades, pero el uso de mismo exige cumplir dos condiciones: ser válido y
estar bien formado.
XML no es sólo la base de HTML, sino que además tiene infinitas aplicaciones, algunas de ellas
estandarizadas y otras definidas por cualquier usuario. Para además asegurar la válidez de los
documentos, pueden definirse DTDs (documenttypedefinition), el cual permite definir la estructura y
sintaxis. Por ejemplo, para comprobar la validez de los documentos HTML, existe un validador
online de la W3C: https://validator.w3.org/
Existen 3 utilizaciones básicas para los lenguajes de marcas:
Diseño y desarrollo de portales web
• Para describir contenido, por ejemplo bases de datos.
• Para definir formato, por ejemplo procesadores de textos.
• Para describir contenido y además dar formato, por ejemplo el lenguaje HTML.
1.2. Historia del HTML
En 1880, Tim Berners-Lee, trabajador de Centro Europeo de Investigaciones Nucleares (CERN),

publica que estaba trabajando en un sistema de hipertexto para compartir archivos a través de
redes TCP-IP, en concreto para lo que hoy se conoce como Internet. Finalmente, en 1990, junto a
Robert Cailliau, presentaron la propuesta ganadora llamada WorldWideWeb (W3).
Durante 1990 se desarrolló el primer sistema que facilitaba la lectura de información, mediante un
navegador web. Inicialmente fue llamado WorldWideWeb, aunque fue posteriormente rebautizado
como Nexus, para evitar confusiones al compartir nombre con la tipología.
La primera propuesta oficial para convertir HTML en un estándar se realizó en 1993 por parte del
organismo IETF (Internet EngineeringTaskForce).El propio lenguaje HTML seguía desarrollándose
y ese mismo año, se creó HTML+, que al igual que su predecesor, nunca se llegó a estandarizar.
En 1995 la IETF creó grupos de trabajo de HTML, consiguiendo ser publicado HTML 3.0 y
convirtiéndose a su vez en el primer estándar oficial de HTML. Entre las grandes mejoras se
encontraban la posibilidad de incorporar applets de java y textos alrededor de imágenes.
En 1998 se publicó HTML 4.0, suponiendo un gran salto con respecto a sus predecesores, al
incluir una gran cantidad de mejoras como la inclusión de hojas de estilo CSS, scripts, mejoras de
accesibilidad, tablas complejas y mejoras en los formularios.
En el año 2000, de forma paralela, fue reescrito HTML 4.0 para cumplir estrictamente los
estándares de XML, creándose XHTML. Las diferencias son pocas, como por ejemplo la
obligatoriedad de escribir las etiquetas en minúsculas o los elementos de etiqueta única precisan
cierre.
Desde la publicación del HTML 4.01, la actividad de estandarización se detuvo por la W3C al dar
mayor relevancia al desarrollo de XML. Ello provocó que en 2004, las grandes organizaciones
Apple, Mozilla y Opera se asociaran en WHATWG (Web
HypertextApplicationTechnologyWorkingGroup), con el objetivo de desarrollar HTML5.
En 2006, el W3C se interesó en el desarrollo de HTML5, para en 2007 unirse al grupo de trabajo
de WHATWG para unificar el proyecto.
La versión definitiva de HTML5, publicó su estándar en 2014 y es la primera vez en la que se ha

desarrollado en paralelo HTML y la variante XHTML. La cantidad de mejoras introducidas son
muchas, pero a groso modo se podría decir que intenta resolver por sí mismo las necesidades de
audio, vídeo, eventos, etc., sin la necesidades de applets externos, además de numerosas
etiquetas para ayudar a la Web Semántica o Web 3.0 y en consecuencia a los buscadores.
2. HTML5
El Lenguaje HTML5, no es complejo en sí, pero como como cualquier otro lenguaje hay que
conocer su propia sintaxis. A lo largo del capítulo se va a realizar una introducción a la última
versión de HTML, aunque siempre hay que tener en cuenta la íntima relación que tiene junto a
CSS y Javascript para dotarlo por un lado de estructura y contenido en la pantalla y por otro de
funcionalidades añadidas.
Por otro lado, los documentos HTML, que por cierto son los más abundantes de entre todos los
formatos digitales, están escritos sobre un fichero de texto plano y pueden ejecutarse en cualquier
navegador con tan sólo guardarlo con la extensión .html.
2.1. Estructura global
Los documentos se encuentran estrictamente organizados. La primera línea deberá ser siempre:
<!DOCTYPEhtml>
Figura 1: Elemento <doctype>
Seguidamente se debe comenzar a construir la estructura HTML, siempre en estructura de tipo

árbol empleando el elemento raíz <html>. Además se especifica el atributo lang para identificar
idioma.
<!DOCTYPEhtml>
<htmllang=”es”>
</html>
Figura 2: Elemento <html>
Las dos siguientes secciones son el <head> y el <body>. El elemento <head> se emplea para
definir título, descripción, hojas de estilos o ficheros javascript externos, etc. En segundo lugar
aparecerá el <body>, donde se incluirá toda la parte visible de la web.
<!DOCTYPEhtml>
<htmllang="es">
<head>
</head>
<body>
</body>
</html>
Figura 3: Elementos <head> y <body>
Dentro de la cabecera se incorporan distintas etiquetas <meta> para añadir metadatos, como por
ejemplo la codificación, la descripción, las palabras clave, etc. Estas etiquetas, al ser únicas,
pueden emplear o no emplear la barra de cierre.
…
<head>
<meta charset="iso-8859-1">
<metaname=”description” content=”Ejemplo de HTML5”>
<metaname=”keywords” content=”HTML5, CSS3, Javascript”>
</head>
…
Figura 4: Elementos <meta>
La etiqueta <title> especifica el título al documento, visualizándose habitualmente en la cabecera

del navegador empleado.
La inmensa mayoría de documentos HTML emplean la etiqueta <link>, la cual permite añadir un
enlace a un fichero externo, pudiéndose ser hojas de estilos, código Javascript o iconos.
…
<head>
<title>Este texto es el título del documento</title>
<linkrel=”stylesheet” href=”misestilos.css”>
</head>
…
Figura 5: Elementos <title> y <link>
2.2. Estructura del cuerpo
La estructura del cuerpo es la definida dentro de la etiqueta <body>. Para ayudar a estructurar el
contenido, inicialmente se hacía uso del elemento <table>, a pesar de que las tablas no tienen esta
finalidad. Hasta que empezó a utilizarse elemento <div>, sobre todo tras una mayor integración del
HTML con CSS y Javascript. Esta etiqueta es mucho más genérica, y aunque no ofrece
información directamente sobre de qué clase de división se trata, esta sigue siendo empleada junto
a otras más específicas aparecidas en esta última versión de HTML.
Actualmente, la mayoría de webs emplean un diseño base similar al que aparece a continuación,
aunque como siempre, pueden optar por otras alternativas.
Figura 6: Ejemplo de estructura dentro del <body>
La etiqueta <header> se emplea para en su interior colocar la cabecera visible de la web, con
elementos como el logo, contacto, etc.
El <nav> es la barra de navegación o menú, aunque haber uno o varios dentro de una misma
página. Para identificar cada una de las secciones del menú, suele emplearse una lista de
opciones, bajo las etiquetas de <ul> para identificar la lista y <li> para los elementos.
…
<nav>
<ul>
<li>inicio</li>
<li>productos</li>
<li>contacto</li>
</ul>
</nav>
…
Figura 7: Uso del elemento <nav>
La información más relevante de la página suele encontrarse dentro de la etiqueta <section>. A su

vez dentro de dicha etiqueta, podemos definir la etiqueta <article>, que sería contenido
independiente al resto de la página. En ese <article> podemos incluir por ejemplo noticias,
comentarios, etc.
Lateralmente a este bloque, suele encontrarse el <aside> o barra lateral, para incorporar datos
relacionados con la información principal, o destacar otros contenidos de importancia.
Por último, en la parte inferior, suele ubicarse el <footer> o pie de página, el cual se emplea para
incorporar información de la web como por ejemplo de contacto o por ejemplo también incorporar
un menú secundario de baja relevancia.
2.3. Texto
Antes de incluir el texto, es necesario identificar las secciones, para determinar la organización de
la información. Para ello se emplean los títulos de sección que son las etiquetas <h1>, <h2>, <h3>,
<h4>, <h5> y <h6>, siendo la primera de ellas la más relevante y la última la menos y pudiendo
usarse cada una de ellas en varias ocasiones.
Entre las distintas secciones, puede incluirse texto dentro de las etiquetas <p>, identificando cada
una de ellas a un párrafo.
<h1>Titular de la página</h1>
<p>Párrafo de introducción...</p>
<h2>La primera sub-sección</h2>
<p>Párrafo de contenido...</p>
<h2>Otra subsección</h2>
<p>Más párrafos de contenido...</p>
Figura 8: Ejemplo de uso de las etiquetas <p>, <h1> y <h2>, justo a su código.
En ocasiones, determinadas palabras o frases han de destacarse y para ello se disponen de

diversas etiquetas que lo permiten. A continuación se muestra una tabla con las más habituales:
Tabla I: Etiquetas para destacar texto
Etiqueta Función Atributos

<em> Destaca con cursiva -
<strong> Destaca con negrita -
<blockquote> Indica que es una cita textual cite=”url”: indica la url origen
title = "texto" - Indica el
<abbr> Indica que es una abreviatura
significado
title = "texto" - Indica el
<acronym> Indica que es un acrónimo
significado
<br> Fuerza un salto de línea -
Muestra texto respetando
<pre> -
espacios
Muestra texto en formato
<code> -
código fuente
2.4. Enlaces
El lenguaje HTML se definió en su día para permitir los vínculos entre documentos, de hecho las
letras “HT” de sus siglas vienen de hipertexto. El elemento en cuestión se denomina anchor en
inglés y enlace web o enlace en castellano.
Los enlaces a páginas dentro de la misma web, pueden ser relativos o absolutos, según pueda
interesar por la estructura del portal web o la programación de la misma. En el caso de emplear las
URLs relativas, es el propio navegador el encargado de hacer la conversión a URL absoluta. La
diferencia entre ambas es la siguiente:
Las URLs absolutas incluyen todas las partes de la ruta: protocolo, servidor y ruta completa.
Las URLs relativas prescinden de parte de la URL para hacerla más breve y parte desde el
directorio actual.
URL absoluta: http://www.ejemplo.com/ruta1/ruta2/pagina2.html

URL relativa: /ruta1/ruta2/pagina2.html
Figura 9: Ejemplos de URL abosluta y relativa
Detalles problemáticos a tener en cuenta en las URLs, es la inclusión en las mismas de espacios o
caracteres especiales como acentos o la letra ñ, siendo más sencillo evitar los nombres de
archivos con estos caracteres o en su defecto es necesario emplear codificaciones alternativas de
esos caracteres, teniendo también en cuenta la codificación del documento HTML.
La etiqueta para los enlaces es <a>, teniendo siempre que incorporar el atributo href para indicar la
URL a la que hace referencia. Se puede enlazar cualquier contenido como pueden ser otras
páginas web, documentos PDF, archivos ZIP, etc.
También se puede emplear para enlazar direcciones de correo electrónico, con la particularidad de
tener que escribir en el la palabra mailto antes de la dirección de e-mail.
<a href="http://www.ejemplo.com/pagina1.html">Enlace a la página 1</a>

<a href=mailto:info@midominio.com>Enviar mail</a>
Figura 10: Ejemplo de hipervínculos a una web y a un email
También es posible enlazar con un punto concreto de una página, siendo necesario en primer lugar
usar la etiqueta <a> con el atributo name, para indicar el punto de retorno. Y en la etiqueta <a> de
origen se indicara en el atributo href la URL (en caso de ser distinta página), seguida de una # y el
nombre indicado en el punto de retorno.
<a name="inicio"></a>
...
<a href="#inicio">Volver al inicio de la página</a>
Figura 11: Enlace a un punto concreto de una página
En el caso de emplear paginaciones, como si fuera un libro o listado de productos, los atributos
start, prev y next son muy interesantes para identificar los puntos de inicio, anterior y siguiente.
2.5. Listas
HTML permite crear 3 tipos de listas para poder agrupar elementos, los cuales tienen significado
de una forma conjunta. Por ejemplo, el menú de navegación es un lugar idóneo para emplearlas.
• Las listas no ordenadas muestran un grupo de elementos en los cuales, el orden, es

indiferente. La etiqueta que define la lista es <ul> y cada uno de los elementos se delimita
dentro de la etiqueta <li>.
• Las listas ordenadas muestran una serie de elementos en los cuales se genera una lista
incremental. La etiqueta que se emplea es <ol> y los elementos también se delimitan con
<li>.
• Las listas de definiciones se emplean para definir términos como si fuera un diccionario,
empleando <dl> para delimitar, y posteriormente <dt> para identificar el término y <dd>
para identificar la definición.
Una de las ventajas, es la posibilidad de poder anidar unas listas dentro de otras, muy útil tanto en
listas no ordenadas u ordenadas, para poder crear sublistas.
<ul>
<li>Inicio</li>
<li>
<strong>Noticias</strong>
<ul>
<li><a href="#">Recientes</a></li>
<li><strong><a href="#">Más leídas</a></strong></li>
<li><a href="#" >Más valoradas</a></li>
</ul>
</li>
<li>
Artículos
<ol>
<li><strong>XHTML</strong></li>
<li>CSS</li>
<li>JavaScript</li>
</ol>
</li>
<li>
Contacto
<dl>
<dt><em>Email</em></dt>
<dd><strong>nombre@direccion.com</strong></dd>
<dt><em>Teléfono</em></dt>
<dd>900 900 900</dd>
</dl>
</li>
</ul>
Figura 12: Ejemplo de listas y visualización en navegador
2.6. Imágenes y objetos
Las webs actuales están llenas de imágenes y son un elemento principal e imprescindible dentro
de ellas para hacer que sean atractivas para el usuario. La etiqueta <img> es la empleada para
incluirlas, teniendo en cuenta que el atributo src, es imprescindible, pues indica la URL de la
imagen a incorporar. Las imágenes pueden a emplear pueden estar en cualquiera de los formatos
más habituales como JPEG, GIF, PNG o BMP, siendo JPEG el más habitual y PNG empleado para
el uso de transparencias.
<imgsrc="logotipo.gif" alt="Logotipo de Mi Sitio" />
Figura 13: Ejemplo de imagen
También pueden incluirse objetos embebidos, como es el caso de applets de Java, vídeos
externos o flash, empleando la etiqueta <object>, e indicando en el atributo data la URL del objeto
y en type el tipo de datos. Pueden anidarse varios object, y en caso de no cargar el primero,
pasará a la segunda opción.
<objecttitle="La Tierra" classid="tierra.py">


<object data="Tierra.mpeg" type="application/mpeg">

<object data="Tierra.gif" type="image/gif">

La <strong>Tierra</strong> vista desde el espacio.
</object>
</object>
</object>
Figura 14: Ejemplo de uso de <object>
2.7. Tablas
Las tablas en HTML son un elemento muy versátil, el cual permite contener elementos simples,
agrupaciones de filas y de columnas, cabeceras y pies de tabla, subdivisiones, cabeceras múltiples
y otros elementos complejos.
Una tabla se identifica con la etiqueta <table> y tiene como elementos imprescindibles en su
interior la etiqueta <tr> para identificar las filas y <td> para identificar las celdas de una fila, es
decir, las columnas. Y si las celdas precisan de una cabecera, además se emplea la etiqueta <th>
en lugar de emplear la <td>.
<table>
<tr>
<thscope="col">Nombre producto</th>
<thscope="col">Precio unitario</th>
<thscope="col">Unidades</th>
</tr>
<tr>
<td>Artículo 1</td>
<td>192.02</td>
<td>1</td>
</tr>
<tr>
<td>2.50</td>
<td>5</td>
</tr>
<tr>
<td>12.99</td>
<td>1</td>
</tr>
<tr>
<th>TOTAL</th>
<td>-</td>
<td>7</td>
</tr>
</table>
Figura 15: Ejemplo de tabla
Varias celdas contiguas también pueden agruparse o fusionarse entre sí, para salir de la estructura
regular inicial, en el que todas las tablas tienen el mismo número de filas y columnas. De esta
forma, empleando el atributo colspan, se puede indicar el número de columnas que va a agrupar
esa celda, y de forma paralela, empleando rowspan, se fusionan filas.
<table>
<tr>
<tdcolspan="2">A</td>
</tr>
<tr>
<td>B</td>
<td>C</td>
</tr>
</table>
Figura 16: Ejemplo de tabla con columnas fusionadas mediante rowspan
Conceptualmente, las tablas pueden distribuirse en tres secciones, para agrupar la cabecera, el
contenido y el pie, de una forma análoga a como se hace con las etiquetas <header>, <content> y
<footer>. Para ello se emplean las etiquetas <thead>, <tbody> y <tfoot>, y deben colocarse
exactamente en este orden, incluyendo dentro de ellas los <tr> de las filas que incorporan.
2.8. Formularios
Los formularios permiten que el usuario de una web interactúe con las aplicaciones web, pasando
desde simples cajas de textos a introducciones de fechas a partir de un calendario y con validación
de la misma gracias a Javascript.
Todo formulario debe estar contenido dentro de su etiqueta <form>, dentro de la cual se incluirán
los botones, cuadros de texto, listas desplegables e incluso otros elementos no específicos como
textos. Además, tienes una serie de atributos propios que son de gran relevancia, siendo los dos
primeros los más habituales:
• action= “url”. Indica la URL que procesa el formulario una vez enviado
• method = "POST o GET".Método HTTP empleado al enviar el formulario. Se recomienda

no usar GET para enviar información sensible.
• enctype = "application/x-www-form-urlencoded o multipart/form-data". Tipo de

codificación empleada al enviar el formulario al servidor.
• accept = "tipo_de_contenido".Lista separada por comas de todos los tipos de archivos

aceptados por el servidor, en caso de permitir adjuntar archivos.
La mayoría de elementos de un formulario se crean mediante la etiqueta <input>, en el que su

atributo type permite diferencia el tipo de control empleado. A continuación se detallan los
principales atributos propios:
• type = "text | password | checkbox | radio | submit | reset | file | hidden | image |
button". Indica el tipo de control.
• name = "texto". Asigna un nombre al control, imprescindible para su posterior tratamiento.
• value = "texto". Valor inicial del control.
• size = "unidad_de_medida". Tamaño del control.
• maxlength = "numero".Longitud máxima.
• checked = "checked". Opción predeterminada para los controles checkbox y radiobutton.
• disabled = "disabled". El control aparece deshabilitado.
• readonly = "readonly". El contenido del control no se puede modificar.
• src = "url". Para botones con imágenes, indica la URL de la imagen.
• alt = "texto". Descripción del control
Para poder diferenciar los tipos de <input>, se identifican a continuación todos ellos junto a una
breve descripción de los mismos.
• text: cuadro de texto libre
• password: cuadro de contraseña. El texto introducido no se muestra en pantalla al

aparecer oculto por asteriscos.
• checkbox: casillas de verificación que permite al usuario seleccionar una o varias de las
opciones.
• radio: casilla de verificación similar al checkbox, pero que sólo permite seleccionar una de
todas las opciones.
• submit: botón de envío del formulario.
• reset: botón de borrado de todo el contenido del formulario.
• file: botón para adjuntar archivos para subirlos al servidor.
• hidden: campo oculto que no se puestra en pantalla.
• image: botón de formulario personalizado incluso con una imagen.
• button: botón sin funcionalidad preestablecida, que permite realizar tareas programadas
mediante Javascript.
<formaction="enviar.php" method="post" enctype="multipart/form-data">

Nombre <br/>
<inputtype="text" name="nombre" value="" size="20" maxlength="30" />
<br/>
Apellidos <br/>
<inputtype="text" name="apellidos" value="" size="50" maxlength="80" />
<br/>
Contraseña <br/>
<inputtype="password" name="contrasena" value="" maxlength="10" />
<br/>
DNI <br/>
<inputtype="text" name="dni" value="" size="10" maxlength="9" />
<br/>
Sexo <br/>
<input type="radio" name="sexo" value="hombre" checked="checked" /> Hombre
<br/>
<input type="radio" name="sexo" value="mujer" /> Mujer
<br/><br/>
Incluir mi foto <input type="file" name="foto" />
<br/><br/>
<input name="suscribir" type="checkbox" value="suscribir" checked="checked"/>
Suscribirme al boletín de novedades
<br/><br/>
<input type="submit" name="enviar" value="Guardar cambios" />
<input type="reset" name="limpiar" value="Borrar los datos introducidos" />
</form>
Figura 17: Ejemplo de formulario
2.9. Multimedia
Si deseáramos añadir archivos multimedia a nuestro HTML, como audios y/o videos, utilizaríamos
las siguientes etiquetas: <video>, <audio> y <embed>
• Con la etiqueta <video> especificaríamos el video que queremos incluir en nuestro HTML.
También indicaremos el tamaño del video en nuestro HTML, es decir, la anchura y altura
en la página. Añadiremos el nombre del archivo en el código, indicando el tipo de archivo
que en este caso sería .mp4. Habrían varios formatos aceptados como mp4, WebM, etc.
<video width=”320” height=”240” controls>

<Source src=”video.mp4” type=”video/mp4”>
</video>
Figura 18: Ejemplo de etiqueta video
• Con la etiqueta <audio>, definiremos sonido o música. No haría falta indicar el tamaño
como en <video>. Definimos también el nombre del archivo de audio. Además de eso
indicaremos el tipo del archivo que queremos que se reproduzca en nuestra página, los
formatos aceptados son: mp3/wav.
<audio controls>
<Source src=”audio.mp3” type=”video/mpeg”>
</audio>
Figura 19: Ejemplo de etiqueta audio
• Con la etiqueta <embed> definimos contenido de una aplicación externa o contenido

interactivo. Deberemos definir la etiqueta <embed> seguido de src, indicando después el
nombre del archivo. El formato disponible es .swf
<embed src="helloworld.swf">
Figura 20: Ejemplo de etiqueta embed
3. Complementos o mejoras del HTML
3.1. Hojas de estilo CSS
Hojas de Estilo en Cascada (Cascading Style Sheets), es un mecanismo que permite describir
cómo se va a mostrar un documento en la pantalla del ordenador, en el móvil o como va a ser
impreso por la impresora. Puede aplicarse a cualquier documento XML, aunque es principalmente
usado para definir las interfaces de los documentos HTML. Su principal ventaja es que un cambio
en la hoja de estilos afectará a todas las páginas vinculadas a la misma.
CSS funciona a base de reglas, realizando declaraciones que se aplican a un documento HTML o
XML. Las Hojas de estilo están compuestas por una o varias reglas y esta a su vez está
compuesta de dos partes: un selector y la declaración.
El selector es el enlace entre el documento y el estilo, especificando los elementos que se van a
ver afectados; mientras la declaración especifica las propiedades que se asignarán al elemento o
elementos englobados en la especificación.
p {
color: red;
text-align: center;
}
Figura 21: Ejemplo de regla CSS
Existen 3 formas principales de emplear un documento CSS desde un documento HTML:
• Hoja de estilo externa que estará vinculada a un documento a través del elemento <link>,
el cual debe ir situado en la sección <head>.
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css">
</head>
Figura 22: Inserción de hoja de estilo externa
• Elemento <style>, en el interior del documento al que se le quiere dar estilo, y que
generalmente se situaría en la sección <head>. De esta forma los estilos serán
reconocidos antes de que la página se cargue por completo.
<head>
<style>
body {
background-color: linen;
}
h1 {
color: maroon;
margin-left: 40px;
}
</style>
</head>
Figura 23: Inserción de hoja de estilo interna
• Estilos directamente sobre aquellos elementos que lo permiten a través del atributo <style>
dentro de <body>. Pero este tipo de definición del estilo pierde las ventajas que ofrecen las
hojas de estilo al mezclarse el contenido con la presentación.
<h1 style="color:blue;margin-left:30px;">Thisis a heading.</h1>
Figura 24: Inserción de hoja de estilo en línea
La versión estandarizada por la W3C actual es CSS3, desarrollada de forma paralela a HTML5,
está compuesta de distintos módulos, los cuales llevan desarrollos independientes y permiten
integraciones paulatinas a los navegadores, según los estados de desarrollo en los que se
encuentren.
3.2. JavaScript
JavaScript apareció ante la necesidad de validación de datos en las conexiones de Internet de baja
velocidad de los años 90, sin tener que enviar los datos y esperar la respuesta del servidor. Por lo
tanto JavaScript (JS), es un lenguaje que se ejecuta en el lado del cliente e implementado por el
navegador web, pero que también puede tener aplicaciones externas a la web, como ejecutarse en
un PDF.
Para evitar duplicados entre empresas, Netscape, empresa que implementó ECMAScript, decidió
estandarizarlo de forma que fuera multiplataforma e independiente, bautizándolo como JavaScript.
La organización internacional para la estandarización (ISO) adoptó el estándar ECMA-262 a través
de su comisión IEC, dando lugar al estándar ISO/IEC-16262.
JavaScript tiene una sintaxis similar a C, a pesar que por otro lado también adopta
especificaciones propias de Java, como su sintaxis y estar orientado a objetos. Una de las grandes
ventajas es que todos los navegadores actuales interpretan sin problemas el lenguaje. Su
desarrollo no ha cesado, como se demuestra en la posibilidad de enviar y recibir información en

tiempo real gracias a la tecnología Ajax.
A partir de la llegada de Ajax, JavaScript ha vuelto a tener un gran éxito, como lo demuestran la
proliferación de frameworks y librerías que basadas en él, intentan mejorar y facilitar las
prestaciones.
Habitualmente JavaScript se emplea para escribir funciones incrustadas en páginas HTML, que
interactúan con el DocumentObjectModel (DOM) de la página. Entre las tareas principales que
permite se encuentra la carga de contenido externo sin tener que recargar la página, animación de
elementos, contenido interactivo, validación de datos y seguimiento a las tareas realizadas por el
usuario.
A nivel de implementación en HTML, JavaScript puede incrustarse en cualquier punto de un

documento HTML.
<script type="text/javascript">
alert("Un mensaje de prueba");
</script>
Figura 25: Ejemplo de código JavaScript incrustado en en HTML
De todos modos, lo más habitual es incluir la programación en un fichero totalmente externo, para
tener independencia y reusabilidad desde otros documentos.
<script type="text/javascript" src="/codigo.js"></script>
Figura 26: Referenciar fichero externo de JavaScript
El último método posible de hacer uso de JavaScript, es dentro del pripio código HTML, haciendo
referencia al objeto en el que se encuentra.
…
<p onclick="alert('Hola)">Un párrafo de texto.</p>
…
Figura 27: Código JavaScript incluido al documento HTML
Tradicionalmente ha sido tildado de inseguro y malicioso, pero realmente no es cierto en su

totalidad. Existen habituales problemas de seguridad debido al cross-site scripting o XSS,
vulnerabilidades que a un atacante le permiten inyectar código JavaScript en páginas web
visitadas, pudiendo llegar a revelar información confidencial del servidor o incluso realizar
inserciones o modificaciones de datos. La única forma de evitarlo completamente, es realizando
una correcta programación en la parte del servidor, aunque los navegadores ya implementan
soluciones parciales a muchos de estos problemas.
3.3. Accesibilidad Web
Los portales web accesibles son aquellos en los cuales, además de facilitar el acceso a los
contenidos de la misma a usuarios discapacitados, ofrece la misma funcionalidad con dispositivos
especiales, como pueden ser dispositivos sin ratón, sin pantalla, o con pantalla muy pequeña, etc.
Para ello, la W3C, a través del proyecto WAI (Web AccessibilityInitiative), trabaja para facilitar el
asceso a las personas con discapacidad, desarrollando pautas de accesibilidad, mejorando las
herramientas para la evaluación y reparación de accesibilidad Web, llevando a cabo una labor
educativa y de concienciación en relación a la importancia del diseño accesible de páginas Web, y
abriendo nuevos campos en accesibilidad a través de la investigación en esta área.
Para hacer que el contenido web sea accesible, se han desarrollado una serie de Pautas de
Accesibilidad al Contenido en la Web (WCAG), que tienen la finalidad de recudir las barreras de las
personas con discapacidad, mediante 14 pautas que proporcionan soluciones de diseño para evitar
que este puede ocasionar problemas de acceso a la información.
Estas pautas tienen uno puntos de verificación, disponibles en

https://www.w3.org/TR/WCAG10/full-checklist, los cuales ayudan a detectar posibles errores. Los
puntos de verificación se encuentran agrupados en 3 niveles de prioridad, siendo los siguientes:
• Prioridad 1: son aquellos puntos que un desarrollador Web tiene que cumplir ya que, de
otra manera, ciertos grupos de usuarios no podrían acceder a la información del sitio Web.
• Prioridad 2: son aquellos puntos que un desarrollador Web debería cumplir ya que, si no
fuese así, sería muy difícil acceder a la información para ciertos grupos de usuarios.
• Prioridad 3: son aquellos puntos que un desarrollador Web debería cumplir ya que, de otra
forma, algunos usuarios experimentarían ciertas dificultades para acceder a la información.
En función del cumplimiento de estos puntos de verificación, se establecen 3 niveles de

conformidad, siendo identificado en los portales web públicos, al ser requisito legal:
• Nivel de Conformidad "A" (A): todos los puntos de verificación de prioridad 1 se

satisfacen.
• Nivel de Conformidad "Doble A" (AA): todos los puntos de verificación de prioridad 1 y 2
se satisfacen.
• Nivel de Conformidad "Triple A" (AAA): todos los puntos de verificación de prioridad 1,2
y 3 se satisfacen.
Para poder validar el contenido de una web con respecto a los niveles de conformidad, existen
diversas webs que ayudan a ello, siendo una de ella esta: http://www.tawdis.net/.
A modo introductorio, se van a indicar los requisitos de accesibilidad exigidos para alcanzar el nivel
A:
• Generales: Proporcionar texto alternativo a imágenes y objetos, asegurar en los textos uso
de colores que se puedan distinguir, marcar las variaciones del idioma del texto o de los
elementos textuales, asegurar su lectura sin emplear hojas de estilos, la información
equivalente para los contenidos dinámicos debe adaptarse a los cambios de los contenidos
dinámicos, ningún elemento debe parpadear en la pantalla, el contenido se debe escribir
con un lenguaje sencillo y limpio.
• Mapas de imagen: proporcionar un enlace textual por cada una de las regiones del mapa
de imagen y utilizar mapas de imagen en el cliente, en vez de mapas de imagen de
servidor.
• Tablas: utilizar cabeceras de fila y de columna, y si la tabla tiene varios niveles de

cabeceras, utilizar las agrupaciones disponibles.
• Frames: indicar un título a cada frame para su identificación y facilitar la navegación.
• Applets y scripts: asegurar que la página también se pueda utilizar cuando no se

ejecutan los applets y los scripts, o proporcionar informaciones accesibles.
• Contenidos multimedia (audio y vídeo): incluir una descripción textual del contenido
multimedia y para los contenidos basados en vídeo o animaciones, sincronizar las
alternativas textuales con la presentación.
• Si no se pueden cumplir los anteriores requisitos, proporcionar una página alternativa con
la mayor cantidad posible de contenidos y que cumpla con los requisitos anteriores.
(1) W3C. https://www.w3.org/
(2) W3Schools.http://www.w3schools.com/
(3) Guerrero, R. (2014). Elaboración de documentos web mediante lenguajes de marcas.

Antequera: IC Editorial.
(4) Pintos, J. (2014). Aplicación de técnicas de usabilidad y accesibilidad en el entorno

cliente.Málaga: IC Editorial.
(5) Diego, J. (2012). El gran libro de HTML5, CSS3 y Javascript. Barcelona: Marcombo ediciones
técnicas.
(6) Herrera, E (2012). Arrancar con HTML5. Curso de programación. México D.F.: Alfaomega
Grupo Editor.
(7) Anido, L. (2013). Web semántica y tecnologías 2.0. Logroño: UNIR, D. L.
(8) Rubiales, M. (2013). HTML5, CSS3 y JavaScript. Madrid: Anaya Multimedia
Tema 38. Comercio electrónico. Pasarelas de
pago. Factura electrónica. Servicios ge-Factura y
FACE
Jorge Sánchez López

Colegiado 0847
El comercio electrónico comprende aspectos relacionados con el desarrollo de la

Sociedad de la Información, la penetración de las nuevas tecnologías de la
información y comunicaciones en la escuela, el hogar, las empresas y las
administraciones. Supone la globalización de las relaciones entre clientes y
proveedores a través de la venta online de todo tipo de productos y servicios. Influye
en el marketing y publicidad, canales de distribución, medios de pago y ha facilitado la
aparición de nuevos modelos de negocio.
La factura electrónica es un justificante de la entrega de bienes o de la prestación de

servicios entre empresas, administraciones y particulares; y tiene los mismos efectos
legales que una factura en papel, aunque está condicionada al consentimiento de su
destinatario (menos en el caso de las administraciones públicas, AAPP, que están
obligadas a aceptar las mismas).
En este tema, se exponen las características y taxonomías básicas del comercio

electrónico, el entorno normativo en el que se desarrolla, así como sus estándares
tecnológicos. Además, también nos centraremos en la factura electrónica y sus
modelos como ejemplo de interrelación electrónica entre los negocios y las
administraciones, y las pasarelas electrónicas de pago como medio para formalizar los
desembolsos de las operaciones comerciales mediante las TIC.
1. Comercio electrónico
1.1. Introducción
Concepto comercio electrónico:
Se refiere a la compra/venta de productos y/o servicios a través de redes electrónicas, a

través de Internet, incluyendo el m-Commerce (comercio a través de dispositivos móviles).
El campo del comercio electrónico es tan amplio que comprende aspectos relacionados con el
desarrollo de la Sociedad de la Información, la penetración de las nuevas tecnologías de la
información y comunicaciones en la escuela, el hogar, las empresas y las administraciones, etc.
Pero fundamentalmente respecto a fenómenos que afectan a las empresas: globalización, nuevos
modelos de negocio, relaciones con clientes y proveedores, marketing y publicidad, canales de
distribución, medios de pago, etc.
El desarrollo de Internet ha transformado de manera radical la forma en que las empresas

desarrollan sus negocios, redefiniendo sus servicios, mercados y canales de distribución.
En este tema, se exponen las ideas generales del comercio electrónico, sus características y
taxonomías. También el entorno normativo en el que se mueve, así como los estándares
tecnológicos. Nos centraremos en la factura electrónica y sus modelos como ejemplo de
interrelación electrónica entre los negocios y las administraciones, y las pasarelas de pago como
medios para cerrar las operaciones comerciales mediante las TIC.
1.2. Desarrollo histórico
Originariamente, comercio electrónico significaba la facilitación de transacciones comerciales

electrónicamente, normalmente utilizando tecnología como EDI (Electronic Data Interchange).
Con la aparición de Internet, pasó a ser "comercio en la red" con la compra de bienes y servicios
vía servidores seguros HTTPS, con tarjetas de compra electrónica y con servicios de pago
electrónico como autorización para tarjeta de crédito.
En el año 2000 el 8 de junio, se publicó Directiva 2000/31/CE del Parlamento Europeo y del
Consejo, relativa a determinados aspectos jurídicos de los servicios de la sociedad de la
información, en particular el comercio electrónico en el mercado interior (Directiva sobre el
comercio electrónico)
Comercio electrónico. Pasarelas de pago. Factura electrónica. Servicios ge-Factura y FACE
En España se reguló mediante la Ley 34/2002 de servicios de la sociedad de la información y de

comercio electrónico.
Y otras leyes como la:
• Ley 59/2003 de Firma Electrónica.
• Ley 56/2007 de Medidas de Impulso de la Sociedad de la Información.
• Ley 25/2007 de conservación de datos relativos a comunicaciones electrónicas.
• Ley 9/2014 General de Telecomunicaciones han introducido modificaciones a la ley de

Comercio Electrónico.
1.3. Normativa legal
La Ley 34/2002 de Servicios de la Sociedad de la Información y Comercio Electrónico

comprende:
Aplicación de la ley a actividades económicas: en concreto a las que se realicen por

medios electrónicos y tengan carácter comercial o persigan un fin económico.
Ausencia de autorización previa: las empresas no necesitan pedir una autorización

previa ni inscribirse en ningún registro para prestar servicios vía telemática.
Obligaciones de información de los prestadores de servicios: deben indicar en su

página web su nombre y datos de contacto, su NIF, si ejercen una profesión regulada, etc.
Obligaciones de colaboración en relación con los contenidos. Los prestadores de

servicios de intermediación no tienen obligación de supervisar los contenidos que alojan,
pero deben colaborar con las autoridades cuando se les requiera bloquear el acceso a ese
contenido o retirarlo.
Normas sobre publicidad en Internet y por correo electrónico: la publicidad debe

presentarse como tal. Por correo electrónico deberá solicitar el consentimiento expreso del
destinatario que puede oponerse en cualquier momento.
Contratación electrónica: validez y eficacia de los contratos que se celebren por vía
electrónica, aunque no consten en soporte papel.
Códigos de conducta: las AAPP deberán fomentar la elaboración y aplicación de códigos

de conducta.
Medios de resolución de conflictos: la Ley potencia los instrumentos de resolución

extrajudicial de conflictos por medios electrónicos.
Ley 56/2007 de Medidas de Impulso de la Sociedad de la Información:
Elimina obligaciones excesivas e innecesarias y flexibiliza las obligaciones en materia de

comunicaciones comerciales y contratación electrónica, para adecuar su uso en
dispositivos móviles.
Ley 9/2014 General de Telecomunicaciones.
Comunicaciones comerciales por correo electrónico o medio de comunicación: se

suprime la obligación de insertar al comienzo del mensaje la palabra "publicidad". Continúa
en vigor la obligación de identificarse claramente como comunicaciones comerciales, así
como la persona en nombre de la cual se realizan.
Disposiciones en materia de cookies: deja de ser requisito que el destinatario deba

realizar una acción expresa para proceder a su configuración. Se dota de régimen
sancionador expreso a conductas relacionadas con la no obtención del consentimiento
previo a la utilización de cookies.
Ley 25/2013 de impuso de la Factura Electrónica y creación del Registro Contable de

Facturas en el Sector Público.
Contempla expresamente sanciones de apercibimiento y multa para las empresas que, estando
obligadas a ello, no ofrezcan a los usuarios la posibilidad de recibir facturas electrónicas o no
permitan el acceso a sus facturas a personas que han dejado de ser clientes.
Se pretende facilitar a los usuarios un medio de interlocución telemática que, mediante el uso de
certificados reconocidos de firma electrónica, les permita realizar, al menos los trámites de:
• Contratación electrónica, modificación y finalización de contratos.
• Consulta de datos del cliente y el contrato suscrito.
• Presentación de quejas, incidencias, sugerencias y reclamaciones.
• Ejercicio de los derechos ARCO que prevé la normativa sobre protección de datos
personales.
1.4. Características
• Ubicuidad: Permite hacer un pedido desde cualquier parte, a cualquier hora.
• Alcance global: el mercado potencial de las empresas de comercio electrónico es toda la

población mundial con acceso a Internet.
• Reducción de costes: una tienda virtual disminuye los costes de entrada al mercado y
reduce el esfuerzo de búsqueda de los consumidores al facilitar la comparación de los
precios y productos.
• Densidad de información: la información está siempre disponible y actualizada.
• Marketing personal: permite personalizar la información a mostrar al consumidor en

función de sus gustos o de compras anteriores.
• Distribución inmediata y sin intermediarios: los proveedores suelen tener unos costes
bajos de distribución al eliminarse intermediarios.
• Beneficios operacionales: la integración del comercio electrónico con el negocio

proporciona una serie de beneficios logísticos. Da más facilidades de abrir nuevos
mercados rápidamente.
1.5. Modelos de negocio en Internet
• Publicidad: las empresas reciben dinero de los anunciantes por situar formatos
publicitarios en páginas web que reciben más tráfico de usuarios o aquellas cuyas palabras
de búsqueda coinciden con las palabras clave del anuncio. (Por ejemplo, Google Adwords).
• Comercio electrónico: venta directa de bienes y servicios. (Amazon).
• Long Tail: se basa en ofrecer gran cantidad de diferentes productos de nicho en pocas
unidades, huyendo del mercado de masas. Venden menos unidades de más cosas.
(Amazon).
• Modelos híbridos de pago y gratuitos (freemium): el usuario recibe una gran parte de
los contenidos sin necesidad de pagar y solo paga por aquel contenido de mayor valor o
exclusivo. (Dropbox).
• Modelo de intermediación: son facilitadores de servicios entre compradores y

vendedores, proporcionan un servicio de valor añadido y cobran una comisión por
transacción (PayPal).
• Plataformas empresariales: plataformas que conectan a compradores y vendedores de

productos y servicios a modo de punto de encuentro donde ambas partes pueden realizar
la transacción a través de los servicios de la plataforma (eBay).
Modelo de afiliación: Un sitio web inserta un formato publicitario de un anunciante y

cobra por la acción generada por el usuario. Si hace click en la web del anunciante, el
afiliado puede cobrar por el tráfico generado en la web del anunciante.
Modelo de Comunidad: Modelo basado en la contribución y participación de los

usuarios. (Groupon).
Dropshipping: variante del comercio electrónico en la que la logística tradicional se ha

transformado; la tienda online se encarga de gestionar la atención al cliente, la
facturación y la generación de bases de datos, mientras la empresa mayorista
almacena, empaqueta y envía los artículos a nombre del comercio online.
Consumerización: referida al boom de los dispositivos móviles y su acceso a Internet,

que ofrece a los consumidores más posibilidades que nunca para comprar online.
Gamificación: utilización de estrategias en las que se integran mecánicas de juego en

la web y en la plataforma de compra, convirtiendo la búsqueda y la compra en un
proceso cómodo, rápido y sencillo.
Big Data: Uso de herramientas y tecnologías para el análisis y gestión de la

información que se genera en la red. De esta forma se pueden diseñar estrategias y
acciones en comercio electrónico.
Internet de las Cosas: la inclusión en Internet de cualquier dispositivo cotidiano, abre

las posibilidades y aumenta el impacto en el comercio electrónico.
Efecto ROPO (Research online, purchasing offline): comportamiento habitual del

consumidor que se informa previamente sobre el producto en Internet, para proceder a
su compra en tiendas físicas. Ahora está creciendo mucho más el ROBO (Research
offline, Buy online).
1.6. Taxonomías
• Business to business: negocios realizados entre empresas. Uso de EDI o factura

electrónica.
• Business to Consumer: comercio entre empresas y consumidores finales.
• Business to Employee: relación comercial entre una empresa y sus empleados.
• Consumer to Consumer: comercio electrónico entre usuarios particulares.
• Goverment to Citizens: relación comercial entre un gobierno y los ciudadanos, para

obtención de información, realización de actos administrativos (Administración Electrónica).
• Goverment to Business: idem pero con personas jurídicas.
• Consumer to Business: cuando un consumidor publica su intención de venta o compra de

un producto, servicio o proyecto a empresas interesadas.
• Goverment to Goverment: transacción electrónica entre administraciones.
• Business to Goverment: comercio donde las empresas proporcionan servicios o

productos a las AAPP.
• Consumers/Citizens to Goverment: relación comercial de ciudadanos con las AAPP.
• Peer to Peer: plataformas que ponen en contacto a iguales (particulares) para que
intercambien productos y servicios.
1.7. Estándares técnicos
La ONU promueve el comercio por su potencial para fomentar el desarrollo económico y erradicar
la pobreza.
• La UN/CEFACT (Centro de las Naciones Unidas para la Facilitación del Comercio y el

Comercio Electrónico), realiza recomendaciones relacionadas con el comercio, normas e
instrumentos.
• Los estándares desarrollados por UN/CEFACT son abiertos y tecnológicamente neutrales.
UN/CEFACT prepara y publica.
• Estándares técnicos: especificaciones que establecen la manera en que se preparan uno

o más estándares y/o recomendaciones.
• Estándares de comercio: especificaciones que proporcionan normas, directrices, y/o

principios relacionados con las actividades en el contexto de la facilitación del comercio o
el comercio electrónico.
• Recomendaciones de la CEPE/ONU (Comisión Económica para Europa de la ONU):

sobre la facilitación del comercio que proporcionan una guía formal para los gobiernos, el
sector privado y la comunidad empresarial.
OASIS (Organization for the Advancement of Structured Information Standards): proporciona

un lugar de encuentro neutral para que diversos actores del comercio electrónico realicen un
esfuerzo de estandarización basado en XML, con independencia de un sector industrial concreto.
EDI: consigue que las empresas intercambien información de forma estructurada. Su aparición es
bastante anterior a Internet.
XML: Lenguaje diseñado para el intercambio de información en Internet.
• Estructura explícita entendible no sólo por la máquina sino también por las personas.
• Validación más sencilla.
• Puede usar fácilmente Internet.
• Es económico de implementar.
• Abre el comercio electrónico a PYMEs.
1.8. Conclusiones
• El comercio electrónico nace como una alternativa de reducción de costes y herramienta

fundamental en el desempeño empresarial.
• El comercio electrónico hace sencilla la labor de negocios con los clientes, reduce los
costes y precios, y garantiza una disponibilidad 24x7.
• Las transacciones electrónicas tienen un alto porcentaje de riesgos, fraude o alteración de

datos personales.
• Existen múltiples modelos de negocio en Internet.
• ROPO y ROBO.
• En los estándares técnicos de comercio electrónico destaca el trabajo de UN/CEFACT.
• Durante mucho tiempo el comercio electrónico se ha identificado únicamente con EDI.
• Otras organizaciones como OASIS han desarrollado UBL (Universal Business

Language), que es una librería estándar de documentos XML, diseñados para representar
documentos empresariales.
2. Pasarelas de pago
2.1. Introducción
Comercio electrónico directo o completo: todas las fases de la contratación incluyendo la

ejecución, el pago y la entrega, se producen vía telemática. Cuando la entrega telemática no fuera
posible por la naturaleza del bien, este hecho no mermaría el carácter directo o completo del
comercio.
2.1.1. Mecanismos de pago
• Pago remoto con tarjeta de crédito.
• Transacciones con seguridad SPA/UCAF (Mastercard).
2.1.2. Pasarelas de pago
Se trata de plataformas proporcionadas habitualmente por las entidades bancarias para que se
incorporen en el proceso de pago de la tienda virtual de los comercios.
• Asumen las tareas de validación de operaciones realizadas con tarjetas de crédito

conectando con las redes privadas de las entidades emisoras de tarjetas de crédito.
• Para garantizar la seguridad de dichas transacciones estas pasarelas emplean

sistemas y protocolos de seguridad.
2.2. Pasarelas de pago de la AEAT
La Agencia Estatal de Administración Tributaria (AEAT) es el organismo público español a través

del cual se realiza un mayor número de pagos telemáticos.
En 1998, con motivo del establecimiento del procedimiento de presentación telemática de

declaraciones para las Grandes Empresas, implementó un sistema de pago de impuestos basado
en la utilización de una técnica de criptografía simétrica o de clave privada a través de un código
NRC para el contribuyente tras el pago de un impuesto.
Procedimiento:
• El contribuyente realiza el ingreso del importe correspondiente al impuesto en la entidad

financiera. Tras obtener el NRC, envía la declaración al portal de la AEAT con el NRC
incorporado, formado mediante la aplicación de un algoritmo DES, Data Encryption
Standard, de la función MAC (Message Authentification Code) con una clave pública
asignada por la AEAT a la entidad financiera.
• Tras las validaciones online pertinentes por el servidor de la AEAT, se devuelve al

contribuyente una copia del documento de ingreso con el NRC y el código electrónico que
garantiza la presentación de la declaración.
Desde el año 2000, la AEAT permite también a los contribuyentes que poseen certificado digital de
usuario realizar el pago electrónico por Internet en una entidad financiera.
• Es una operación de cargo en cuenta que consiste en la transferencia de una determinada

cantidad de dinero de una cuenta del contribuyente a una cuenta restringida del Banco de
España en dicha entidad, como forma de pago de determinado impuesto y periodo.
• El banco toma confianza en la transacción al incorporar a ésta un código cifrado de la

operación (MAC) generado por la AEAT y enviado al ordenador del contribuyente mediante
un applet descargado.
• Tras el pago, el contribuyente puede imprimir un recibo justificante del mismo y liberatorio
ante la administración.
• Todos estos sistemas utilizan protocolo de seguridad SSL, tanto en la transmisión de datos
entre cliente y servidor como entre servidores.
En la actualidad la AEAT permite el pago de impuestos contra cuentas y mediante el uso de

tarjetas de crédito o débito asociadas a las cuentas. El procedimiento es similar al anterior, pero
con el paso adicional de comunicación entre las entidades financieras y las entidades emisoras de
las tarjetas de crédito.
Solamente la AEAT puede garantizar la generación de los NRC, ya que custodia las claves
maestras originarias.
2.3. Pasarela de pago de la Generalitat Valenciana (GV)
La Consellería de Hacienda y AAPP pone a disposición de los usuarios un sistema de ayuda que,
mediante las nuevas tecnologías, facilita el pago de las autoliquidaciones y tasas vía web,
utilizando la pasarela de pagos de la GV.
Este sistema se llama PTG (Pago Telemático Genérico) se realiza a través del portal tributario de
la Consellería.
El sistema es análogo al de la AEAT. Se basa en el envío de peticiones de cargo en cuenta de

autoliquidación extrayendo los datos del titular de la cuenta automáticamente de la identificación en
el sistema mediante certificado digital.
Por cada petición de cargo en cuenta y tras una serie de validaciones, se gestiona el pago
mediante la pasarela, en la cuenta indicada en la petición. Posteriormente, se generará un
justificante de pago con todos los datos resultantes del cargo en cuenta, incluyendo el NRC.
3. La factura electrónica
3.1. Introducción
3.1.1. Qué es una factura
Una factura es un documento que refleja la entrega de un producto o la provisión de servicios,

junto a la fecha de devengo, además de indicar la cantidad a pagar como contraprestación.
En la factura se encuentran los datos del expedidor y del destinatario, el detalle de los productos y
servicios suministrados, los precios unitarios, los precios totales, los descuentos y los impuestos.
Se la considera como el justificante fiscal de la entrega de un producto o de la provisión de un

servicio, que afecta al obligado tributario emisor (el vendedor) y al obligado tributario receptor (el
comprador). El original debe ser custodiado por el receptor de la factura.
Habitualmente, el emisor de la factura conserva una copia o la matriz en la que se registra su

emisión.
La factura correctamente cumplimentada es el único justificante fiscal, que da al receptor el

derecho de deducción del impuesto sobre el valor añadido (IVA). Esto no se aplica en los
documentos sustitutivos de factura, recibos o tickets.
En Europa, la normativa de facturación se regula por la Directiva 77/388/CEE que define, además
impuestos como el IVA cuya traducción al inglés VAT (Value Added Tax) es también de uso
amplio.
Esta Directiva se ha ido modificando a lo largo de los años y su texto refundido se recoge en la
Directiva 2006/112/CE del Consejo, de 28 de noviembre de 2006, relativa al sistema común del
impuesto sobre el valor añadido.
La Identificación tributaria en la Unión Europea uniformiza la forma de codificar a las empresas

para facilitar el control tributario.
Las facturas pueden ser:
• Ordinarias: documentan la operación de suministro.
• Rectificativas: documentan correcciones de una o más facturas anteriores, o bien

devoluciones de productos, envases y embalajes o comisiones por volumen.
• Recapitulativas: documentan agrupaciones de facturas de un período.
Además, existen las siguientes variantes:
• Pro-forma: documenta una oferta, con indicación de la forma exacta que tendrá la factura
tras el suministro. No tienen valor contable ni como justificante.
• Copia: documenta la operación para el emisor, con los mismos datos que el original. Debe
llevar la indicación de copia para permitir distinguirla del original.
• Duplicado: documenta la operación para el receptor, en caso de pérdida del original. La

expide el mismo emisor que expidió el original y tiene los mismos datos que el original.
Debe llevar la indicación de duplicado para permitir distinguirla del original, especialmente
para el caso de que reaparezca el original.
Es interesante mencionar que las tradicionales “Notas de Abono” no se contemplan en la

normativa, aunque su función se puede cubrir con las “Facturas Rectificativas”. Cabe identificar
ambos documentos siempre que se incluya la mención obligatoria “Factura rectificativa” y
opcionalmente, a título informativo, la de “Nota de Abono” y se consignen los signos de las
cantidades de forma correcta.
3.2. Qué es la factura electrónica
Una factura electrónica tiene los mismos efectos legales que una factura en papel. Es un
justificante de la entrega de bienes o la prestación de servicios.
Se expide y se envía en formato electrónico y está condicionada al consentimiento de su

destinatario. Sin embargo, las AAPP están obligadas a aceptar las mismas.
Están reguladas por el Real Decreto 1619/2012 por el que se aprueba el Reglamento que regula
las obligaciones de facturación, que comprende:
• Obligación de expedir factura.
• Tipos de factura: completa u ordinaria y simplificada.
• Expedición con terceros.
• Contenido de la factura y medios de expedición.
• Requisitos de la factura: legibilidad, autenticidad e integridad.
• Especificidades de la factura electrónica.
• Plazos.
• Otras facturas: recapitulativa, duplicados, rectificativas.
• Regímenes especiales.
• Conservación de facturas y otros documentos.
La facturación electrónica consiste en la transmisión de las facturas o documentos análogos entre

emisor y receptor por medios electrónicos (ficheros informáticos) y telemáticos (de un ordenador a
otro), firmados digitalmente con certificados cualificados, con la misma validez legal que las
facturas emitidas en papel.
El proceso de facturación es un proceso importante para cualquier empresa, una relación basada
en documentos en formato papel que para ser generados y procesados precisan del empleo de
grandes cantidades de recursos y para los que las empresas se ven obligadas a realizar muchas
tareas de forma manual. Un buen proceso administrativo de estos documentos tiene como
consecuencia no sólo un buen control de compras y ventas, sino el cumplimiento de las
obligaciones tributarias de cada empresa. Sin embargo, todo ello resulta más complicado en un
proceso basado en papeles y que requiere la intervención manual.
Las denominaciones “factura electrónica”, “factura telemática” y “factura digital” son equivalentes,
si bien la denominación utilizada en la normativa es “remisión electrónica” o “remisión por medios
electrónicos” de factura.
Aclarado esto, podemos definir la Factura Electrónica como el documento tributario generado por
medios informáticos en formato electrónico, que reemplaza al documento físico en papel, pero que
conserva su mismo valor legal con unas condiciones de seguridad no observadas en la factura en
papel.
El nuevo marco legal y tecnológico ofrece la oportunidad a las empresas de disponer de una nueva
vía para gestionar las facturas:
• Conservar los datos de las facturas. No es necesario conservar las facturas emitidas sino
la “matriz” o base de datos que permite generarlas.
• Asegurar legibilidad en formato original.
• Garantizar acceso completo a las facturas: visualización, búsqueda selectiva, copia o

descarga en línea e impresión.
• En caso de emisión de factura electrónica: firmar electrónicamente la factura o delegar esta

acción en un tercero o en el Receptor.
Las facturas electrónicas se pueden emitir en diferentes formatos (EDIFACT, XML, PDF, html, doc,
xls, gif, jpeg o txt, entre otros) siempre que se respete el contenido legal exigible a cualquier
factura y que se cumplan ciertos requisitos para la incorporación de la firma electrónica reconocida
(qualified electronic signature, en inglés).
Llamaremos Factura Electrónica al documento tributario generado por medios informáticos en

formato electrónico, que reemplaza al documento físico en papel, pero que conserva su mismo
valor legal con unas condiciones de seguridad no observadas en la factura en papel.
En rigor, el reglamento establece que existen dos formas concretas de intercambiar documentos
electrónicos a las que se les presume un nivel de fiabilidad alto, sin descartar que puedan existir
otras. Estas dos formas garantizan la autenticidad e integridad que son los verdaderos requisitos
que se exigen a los documentos.
Por un lado, el empleo de una firma electrónica y por otro el uso de sistemas EDI en los que las
entidades por cuya intermediación se intercambian los mensajes aportan esas cualidades a los
documentos intercambiados.
3.2.1. Tipos
Con formato estructurado: facilita su tratamiento automatizado. UBL o Facturae, EDIFACT.
Con formato no estructurado: contienen una imagen, se requiere una intervención manual para
ser introducida en los sistemas informáticos. Facturas en papel escaneadas o en formato PDF.
3.3. La factura electrónica dentro del proceso contable global
La factura electrónica no debe entenderse como un proceso aislado, sino como un elemento
integrado dentro del conjunto de gestiones financieras y del flujo de compras y ventas de una
entidad.
Tenemos que considerar la factura como la punta del Iceberg que representa el proceso de gestión
de compras y ventas de la empresa, en el que con frecuencia nos encontramos la factura como
uno de los últimos resultados tras el tránsito habitual de presupuesto, solicitudes de compra,
aprobaciones, albaranes, apuntes contables o procesos de gestión de almacén.
Tenemos que considerar la factura como la punta del Iceberg del proceso de gestión.
Una buena gestión electrónica en todos los pasos y documentos previos facilitará en gran medida
la implantación de la factura electrónica y multiplicará exponencialmente los beneficios de la
misma.
Por otro lado, acometer el proyecto de incorporar la Factura Electrónica a la gestión de una
empresa, habitualmente implicará revisar el proceso de emisión y recepción de facturas y afectará
a más áreas de gestión de las que puede parecer obvio.
3.4. Funcionamiento
A grandes rasgos, el proceso de facturación electrónica lo forman dos procesos básicos y

diferenciados en los sistemas de gestión de facturas, y que corresponden a cada interlocutor:
emisión y recepción de facturas.
1. En la emisión, el emisor, con la conformidad del receptor, transmite a éste por medios
telemáticos la Factura Electrónica (que incluye una firma electrónica) y conserva Copia o
Matriz (la Base de Datos). No es necesario conservar los documentos electrónicos
firmados.
2. El receptor, recibe la factura en formato digital y la conserva en soporte informático, en el

formato en el que lo recibió, para su futura consulta e impresión, si fuera necesario. Al ser
la factura un documento firmado electrónicamente, debe guardar la información relativa a la
comprobación de la validez de la firma electrónica.
Proceso simplificado de facturación electrónica
La factura que se gestiona en un ordenador, se transmite a otro telemáticamente. Éste la conserva

de forma electrónica y desde él, de ser preciso, se pone a disposición de la Administración
Tributaria por vía telemática. Los usuarios llevan a cabo toda la operativa en sus ordenadores.
De esta forma ya no se exige imprimir la factura para que ésta sea válida, legal y fiscalmente y,
todo el tratamiento (emisión, distribución y conservación) puede realizarse directamente sobre el
fichero electrónico generado por el emisor.
En la emisión, el emisor, con la conformidad del receptor, transmite a éste por medios telemáticos
la factura electrónica (que incluye una firma electrónica) y conserva copia en la matriz (BD). No es
necesario conservar los documentos electrónicos firmados, pero debe garantizar acceso completo
a las facturas: visualización, búsqueda, copia o descarga en línea o impresión.
El receptor, recibe la factura en formato digital y la conserva en soporte informático, en el formato

en que la recibió, para su futura consulta e impresión, si fuera necesario. Debe guardar la
información relativa a la comprobación de la validez de la firma electrónica, y como el emisor,
garantizar el acceso completo a las facturas.
De esta forma todo el tratamiento puede realizarse sobre el fichero electrónico generado por el
emisor (sin necesidad de imprimir para que sea legal y fiscalmente válida).
Se permite delegar la ejecución material de la facturación, bien en los destinatarios (autofactura) o

en terceros mediante la contratación de sus servicios (subfacturación), pero con la responsabilidad
legal del sujeto pasivo obligado a la expedición.
3.5. Ventajas, beneficios y ahorros de la factura electrónica
La factura electrónica genera grandes beneficios a las empresas que la utilizan, tanto del lado del
emisor como del receptor. Existen muchas razones para adoptar la factura electrónica, que van
desde las puramente económicas hasta los ecológicas.
Dentro de las ventajas comúnmente aceptadas, se presentan las siguientes:
• Ahorro de costes: tanto del lado del emisor como del receptor. Derivado de la supresión
del papel, el abaratamiento de los medios de comunicación electrónicos (en contraposición
a los medios tradicionales de envío postal), eliminación de los gastos de franqueo, gastos
derivados de la introducción manual de datos, etc.
• Mejora de la eficiencia: la liberación de tareas administrativas, permite destinar los

recursos humanos a aspectos productivos en las compañías.
Integración con ERPs: desde el punto de vista del emisor continúa el proceso que ya
se está realizando electrónicamente. Un simple click desde el ERP y la factura es
emitida y enviada.
Optimización de la tesorería: la automatización permite cuadrar los apuntes

contables y comparar documentos (albarán / factura), minimizando a la vez el margen
de error humano.
Obtención de información en tiempo real: permite verificar el estado en el que se

encuentra una factura y toda su información asociada (errores, rectificaciones, cobros,
pagos, recepción de mercancías, albaranes,...) de forma exacta y actual.
Reducción de tiempos de gestión: la inmediatez del envío y recepción de facturas

por medios telemáticos convierte este trámite en un elemento que deja de tener
sentido. Además, permite solucionar las discrepancias en muy poco tiempo.
Agilidad en la toma de decisiones: la inmediatez de las comunicaciones permite

adoptar decisiones, como la necesidad de financiación, en un espacio más corto de
tiempo.
Administración y contabilidad automatizadas: la integración en los sistemas de la

empresa permite que toda la inserción de datos y las operaciones contables requieran
mucha menos participación humana.
Control de acciones erróneas: a través de sistemas de alertas que detectan

discrepancias entre operaciones de contabilidad y facturación o en la aplicación de
tipos erróneos.
Uso eficaz de recursos financieros: la adopción de la factura electrónica favorece el

acceso a medios de financiación como el factoring o el confirming.
Se consigue, en definitiva, una mayor calidad de servicio que repercute a su vez en una mayor
competitividad de la empresa.
3.6. Legibilidad, autenticidad e integridad
Todas las facturas, sean electrónicas o en papel deben garantizar:
3.6.1. Legibilidad de la factura
La legibilidad la facilita el programa informático que la crea o recibe (facturas electrónicas).
3.6.2. Autenticidad de origen
Garantizar la identidad del obligado a su expedición y del emisor de la factura.
3.6.3. La autenticidad y la integridad se pueden garantizar de varias formas
• Mediante firma electrónica avanzada basada en un certificado reconocido.
• Mediante intercambios electrónico de datos EDI.
• Mediante otros medios que los interesados hayan comunicado a la AEAT con carácter
previo y hayan sido validados por la misma.
• Mediante los controles de gestión usuales de la actividad empresarial o profesional del

sujeto pasivo, siempre que permitan crear una pista de auditoría que establezca la
conexión entre la factura y le entrega de bienes o prestación de servicios que la misma
documenta.
3.6.4. Integridad del contenido
Integridad de la factura, es decir, que no ha sido modificado.
3.7. FACe
Es una plataforma implementada por la Administración General del Estado (AGE) que permite a
proveedores la remisión de las facturas a aquellos órganos de la administración que tienen la
posibilidad de recibir facturas electrónicas.
El sistema remite la factura electrónica al órgano destinatario, simplificando a los proveedores el

envío de las mismas, al centralizar en un único punto todos los organismos de la AGE y unificar
el formato de factura electrónica.
El sistema proporciona a los proveedores:
• Un portal web donde pueden presentar sus facturas electrónicas en formato facturae 3.2
o superior.
• Una interfaz de Web Services para el envío automático de las facturas desde sus sistemas
de gestión económica.
Y a las AAPP:
• Un portal de gestión accesible desde el Portal de Entidades Locales, el de las

Comunidades Autónomas (CCAA) y el Portal para la Gestión Administrativa, donde los
destinatarios pueden:
Gestionar las facturas recibidas, descargarlas y notificar el estado de tramitación al

proveedor.
• Interfaces de Web Services que permiten la recepción automática de las facturas en sus
sistemas de gestión económica.
3.8. Factura-e
Desde 2007, la AGE tiene un formato oficial de factura electrónica, obligatorio para expedir
facturas a la AGE y sus organismos vinculados. Es un formato basado en XML, descrito mediante
un esquema XSD cuyos elementos principales son:
• Bloque 1: Datos generales.
• Bloque 2: Datos del emisor, receptor y en su caso del tercero.
• Bloque 3: Datos comunes de las facturas (identificación, fechas, importes).
• Bloque 4: Detalle de la factura.
• Bloque 5: Datos de Firma electrónica.
La política de firma asociada al formato Facturae fija la realización de la firma de forma

"enveloped", es decir, como un elemento más de la factura. Define dos perfiles posibles para la
firma electrónica avanzada: básico que se corresponde con XADES-EPES y otro con la
información de validación XADES-XL.
3.9. Conclusiones
• Todas las facturas están reguladas por RD 1619/2012.
• Las facturas electrónicas deben garantizar legibilidad, autenticidad e integridad.
• Pueden presentarse en formato estructurado (XML, EDIFACT) o no estructurado

(escaneo).
• Las obligaciones de facturación también se regulan en el RD 1619/2012.
• En 2013 se crea la Ley 25/2013 para el impulso de la facturación electrónica y la creación

de un registro contable.
• Posteriormente se creó el Punto general de Registro de Entrada de Facturas (FACe).
• El estándar oficial de la AGE actualmente es Facturae.
Wikipedia: definición comercio electrónico
Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio

electrónico. Boletín Oficial del Estado. Páginas de la 1 a la 36.
Ley 59/2003, de 19 de diciembre, de firma electrónica. Boletín Oficial del Estado. Páginas de la 1 a
la 29.
Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Boletín

Oficial del Estado. Páginas de la 1 a la 19.
Ley 9/2014, de 9 de mayo, General de Telecomunicaciones. Boletín Oficial del Estado. Páginas de
la 1 a la 110.
Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y creación del registro

contable de facturas en el Sector Público. Boletín Oficial del Estado. Páginas de la 1 a la
18.
Real Decreto 1619/2012, de 30 de noviembre, por el que se aprueba el Reglamento por el que se
regulan las obligaciones de facturación. Boletín Oficial del Estado. Páginas de la 1 a la 26.
Portal General de Entrada de Facturas electrónicas de AGE www.facturae.gob.es.
Tema 39. Servicios de autenticación. Certificados
digitales. Localización de claves públicas.
Servicios de directorio. Marcos de autenticación.
Otras técnicas de autenticación
Daniel Vicente Perpiñá Castillo

Colegiado 0275
La autenticación ha llegado a ser crucial en nuestros días. Por cuestiones de

seguridad todos los sistemas de información actuales deben incorporar los
mecanismos necesarios para poder efectuar las verificaciones oportunas respecto de
la veracidad de las entidades participantes en los procesos más críticos.
Esta autenticación se implementa principalmente a través de la identificación digital lo

que requerirá de servicios de autenticación que nos permitan demostrar a otras
entidades que realmente somos quienes decimos ser. Los certificados digitales
tendrán en este sentido un papel determinante.
Como extensión de los certificados digitales analizaremos una de las opciones que
más trascendencia puede haber tenido en el ámbito jurídico-administrativo: la firma
electrónica.
Los certificados digitales servirían de poco si los destinatarios de nuestros mensajes

no pudieran obtener de una manera relativamente sencilla nuestra clave pública.
Tanto los anillos de confianza como las infraestructuras de clave pública permiten que
los usuarios puedan intercambiar sus claves públicas.
Veremos que los servicios de directorios, sustentados por certificados digitales, son un
tipo concreto de base de datos que nos devuelve información a partir de la
identificación de una entrada (el DN) o bien a partir de búsquedas en el directorio. Nos
centraremos en los servicios de directorios de sistemas operativos de red basados en
LDAP. Concluiremos esta parte describiendo cuáles son las operaciones que los
clientes pueden realizar con un servicio de directorio.
Cuando existe interacción entre diferentes dominios de identidades surgen los

modelos federados y los modelos delegados. Afrontaremos OpenID como método
popular distribuido para la gestión de identidades y completaremos este apartado con
otra tecnología como Kerberos.
Finalmente detallaremos otras técnicas de autenticación también muy extendidas

como son los tokens, factores biométricos y algunos protocolos de autenticación.
1. Servicios de autenticación
Autenticar es establecer o confirmar a algo o a alguien como real.
La autenticación es un procedimiento mediante el cual una entidad demuestra su identidad ante

otra. Se consigue realizando una propuesta de identidad, y poseyendo las credenciales que
permitan demostrarlo.
En lo que a seguridad informática se refiere, la autenticación es una de las tres partes que
componen la triple A (AAA): Authentication (Autenticación), Authorization (Autorización),
Accounting (Auditoria).
Los métodos de autenticación se agrupan en función de aquello que es utilizado para la

verificación de la identidad, a saber:
• Algo que sólo nosotros sabemos, como por ejemplo una contraseña asociada a un nombre
de usuario. Un ejemplo del uso de contraseña se daría cuando accedemos con nuestro
usuario en el inicio se sesión y nos autenticamos mediante ese nombre de usuario y la
contraseña como credencial. Nos estaríamos identificamos por lo que sabemos.
• Algo que sólo nosotros tenemos, como por ejemplo, tarjetas de testimonio (token). Un
ejemplo de tokens sería acceder a edificio con vigilancia y que nos pidieran que nos
identificáramos con la tarjeta que llevara nuestro nombre, apellidos, departamento donde
trabajamos, etc. Nos estaríamos identificando por lo que tenemos.
• Alguna característica biológica que nos hace únicos frente a otras entidades, como por
ejemplo, cualquiera que la biometría nos permita verificar. Un ejemplo de identificación
biométrica sería el lector de huellas digitales, tan popular en dispositivos móviles. Nos
estaríamos identificando por lo que somos.
El método mayormente empleado en la autenticación es el par usuario-contraseña. La robustez de

este método depende de la contraseña empleada: cuanto mayor sea su longitud en caracteres y
más variedad de caracteres incorpore, más robusta será.
Con las contraseñas deberemos aplicar ciertas políticas de seguridad para que resulten confiables:
• No debe estar anotada en ningún soporte físico y/o digital. Deberá ser memorizada.
• No debe ser compartida. Nadie más debe saber la contraseña.
Servicios, marcos y técnicas de autenticación. Certificados. Clave pública. Servicios de directorio
• Deberá ser compleja. Es recomendable que incluya caracteres especiales, mayúsculas y/o
números, o que incluya oraciones en vez de palabras, (password vs passphrase).
• Deberá ser elaborada, no pudiendo contener apellidos, ni fechas de nacimiento, ni ningún

dato afín al usuario.
Existen sistemas de autenticación que combinan uno o varios mecanismos de autenticación, a los
que podemos denominar:
• Autenticación de factor único. Solo se emplea un mecanismo.
• Autenticación de factor doble. Se emplean dos mecanismos.
• Autenticación multifactor. Se emplean varios factores.
Los mecanismos de autenticación compleja dependen de que un usuario proporcione información

que sólo él sepa y de que algún dato personal pueda ser verificado. Para que estos mecanismos
sean viables deben reunir algunas características, como:
• Fiabilidad: Debe tener una tasa de fallos con tendencia a cero. Es imposible crear un
sistema 100% libre de fallos, pero deberá ser un sistema lo suficientemente robusto para
evitar tener fallos.
• Viabilidad: Deber ser viable su implementación. Si el valor del recurso protegido es inferior
al coste de implementación es un sistema inviable.
• Integridad: Debe ser capaz de resistir múltiples ataques.
• Amigable: Al fin y al cabo, son los usuarios los que utilizarán el sistema.
1.1. Identificación digital
Se entiende por Identificación Digital (ID) al conjunto de mecanismos y medios que permiten
garantizar la identidad de una persona física o jurídica en entornos digitales, incluyéndose también
aquí a los que propiamente gestionan y administran estos servicios.
La identificación digital se sustenta en algún tipo de información digital que pueda acreditar la
identidad de su titular en un procedimiento normalizado y que, además, en el ámbito
administrativo, también permita la firma electrónica de documentos.
La Identificación Digital surge ante la necesidad de regular las transacciones comerciales y

administrativas, para así evitar el fraude y garantizar la identidad de las partes implicadas. Debe
garantizar cuatro aspectos básicos entre todas las entidades involucradas:
• Autenticación: La entidad es quien dice ser.
• Autorización: La entidad tiene acceso a la información requerida.
• Integridad: Se tiene la certeza de que la información es la misma que en origen.
• Confidencialidad: Sólo el destinatario y el emisor conocen acerca de esa información.
Los medios más habituales de Identificación Digital son:
• Las tarjetas RFID (Radio Frequency IDentification): En castellano, Identificación por

Radiofrecuencia. Las tarjetas RFID son un sistema de almacenamiento y recuperación de
datos de manera inalámbrica que usa dispositivos denominados etiquetas o tarjetas RFID.
El propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto
(similar a un número de serie único) mediante ondas de radio. Las tecnologías RFID se
agrupan dentro de las denominadas Auto ID (Automatic IDentification, o IDentificación
Automática). Las etiquetas RFID (RFID Tag, en inglés) son unos dispositivos pequeños,
similares a una pegatina, que pueden ser adheridas o incorporadas a un producto, un
animal o una persona. Contienen antenas para permitirles recibir y responder a peticiones
por radiofrecuencia desde un emisor-receptor RFID. Las etiquetas pasivas no necesitan
alimentación eléctrica interna, mientras que las activas sí lo requieren. Una de las ventajas
del uso de radiofrecuencia (en lugar, por ejemplo, de infrarrojos) es que no se requiere
visión directa entre emisor y receptor.
• Las tarjetas inteligentes por contacto: Son del mismo tamaño de una tarjeta de crédito con
un microprocesador y una memoria que se pueden usar con un lector de tarjetas para
acceder a sistemas informáticos.
• DNI-e: Es el documento emitido por la autoridad oficial del Estado y que permite identificar
a la población tanto de manera personal como virtual. Tiene el tamaño de una tarjeta de
crédito y dispone de un chip de seguridad con información almacenada en su interior,
como pueden ser claves privadas y claves públicas de su propietario.
• Sistemas token: Dispositivos que permiten la autenticación y validación de personas o

entidades y que se conectan normalmente a través de un puerto como el USB.
• Sistemas biométricos: Sistemas de reconocimiento por huella dactilar, por voz, por firma,
ocular, etc.
• Certificados Digitales: Certificados emitidos por Autoridades Certificadoras (CA) que avalan
la acreditación de su propietario.
1.2. Firma Digital
La firma digital es el conjunto de datos en forma electrónica, consignados junto a otros o asociados
con ellos, que pueden ser utilizados como medio de identificación del firmante.
La firma digital avanzada es la firma electrónica que permite identificar al firmante y detectar
cualquier cambio posterior de los datos firmados, que está vinculada al firmante de manera única y
a los datos a que se refiere y que ha sido creada por medios que el firmante puede utilizar, con un
alto nivel de confianza, bajo su exclusivo control.
El concepto de firma digital surgió en 1976 cuando Diffie y Hellman idearon el criptosistema híbrido
de clave asimétrica o pública.
La función principal de una firma digital es garantizar tanto la identidad del firmante como la
integridad del mensaje. Para ello, el firmante generará mediante una función “hash”, un “resumen”
también llamado “huella digital” del mensaje. Este “resumen” o “huella digital” será cifrado con su
clave privada y el resultado es lo que se denomina firma digital, que será adjuntada al mensaje
original.
La función hash es un algoritmo matemático que permite calcular un valor resumen a partir de los
datos a ser firmados. Este valor es único para esos datos de entrada. Por ejemplo, si tenemos un
texto, el resultado de la función hash es un número que identifica inequívocamente al texto. Éste
número es lo que se conoce como “huella digital”. Si se adjunta este número al texto original, el
receptor del mensaje podrá comprobar la integridad del mensaje recibido ya que el destinatario
podrá generar la misma “huella digital” aplicando la misma función hash al mensaje original. Si la
“huella digital” generada mediante la función hash fuese firmada digitalmente por el emisor, el
destinatario podrá, además, comprobar la autoría del emisor, descifrando la firma digital con la
clave pública del firmante, lo que dará como resultado, de nuevo, la “huella digital” o “resumen” que
podrá ser comparada con la que el destinatario obtuvo por su cuenta.
Por ello, a la firma digital se le confiere la misma validez jurídico-administrativa que a la firma
manuscrita, ya que cumple con los requerimientos de integridad y no repudio.
El último paso consistirá en asociar la clave privada y la clave pública con la identidad de su
propietario, evitando así posibles fraudes de identidad. Llegados a este punto entran en juego los
Certificados Digitales y las Autoridades de Certificación (CA), que son los mecanismos y
organismos encargados de validar la identidad de una persona o entidad. De este modo quedaría
cubierta la autoría y por tanto la autenticación de la información firmada digitalmente.
No obstante, este tipo de operaciones de firma electrónica y de verificación de identidades no

están pensadas para que las lleve a cabo el usuario, sino que se utiliza software que automatiza
tanto la función de calcular el valor hash como su verificación posterior. El software debe efectuar
varias validaciones, entre las cuales se pueden mencionar:
• Vigencia del certificado digital.
• No revocación del certificado digital.
• Inclusión de sello de tiempo.
1.3. Firma Electrónica
La firma electrónica consiste en la atribución de efectos legales a la firma digital.
La firma electrónica y la firma digital son iguales, pero a efectos legales, con la firma electrónica
podemos, entre otras cosas, firmar documentos oficiales en las oficinas virtuales de las
instituciones del Estado.
La Firma Electrónica se vincula a un documento para acreditar la identidad del autor, para señalar
conformidad (o disconformidad) con el contenido, para indicar que se ha leído o, según el tipo de
firma, para garantizar que no se pueda modificar su contenido.
La firma electrónica garantiza las propiedades de:
• Integridad: Garantiza que nadie ha modificado el mensaje original. Un sólo bit modificado
dará error en la verificación de la firma.
• Identidad: Garantiza que la identidad del firmante es real.
• No repudio: Garantiza que el mensaje no será repudiado. Ante terceras partes, el mensaje
firmado por el emisor prueba su autoría ya que sólo él mismo conoce de su clave privada.
Las firmas digitales y electrónicas están basadas en el sistema de clave pública.
Los países de la Unión Europea se rigen por la Directiva 1999/93/CE de 13 diciembre, por la que
se establece un marco comunitario para la firma electrónica. Posteriormente, cada país miembro
realiza la transposición de la Directiva dentro de su legislación de la forma que vea más
conveniente.
En particular, dentro de la legislación española, se regula la firma electrónica en la Ley 59/2003, de

19 de diciembre, donde define dos tipos de firma electrónica en el título I:
"Disposiciones generales, artículo 3. Firma electrónica y documentos firmados electrónicamente"
1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o

asociados con ellos, que pueden ser utilizados como medio de identificación del firmante. Por
ejemplo, un PIN o una firma electrónica. Este tipo de firma no tiene efectos jurídicos totales. No es
suficientemente segura, ya que no se garantiza que haya sido creada por el supuesto firmante;
puede tratarse de una firma reproducible por un usuario malintencionado.
2. La firma electrónica avanzada permite identificar al firmante y detectar cualquier cambio ulterior
de los datos firmados; está vinculada al firmante de manera única y a los datos a que se refiere,
siendo creada por medios que el firmante puede mantener bajo su exclusivo control. Puede ser
considerada no suficientemente segura si su algoritmo es débil o si ha habido un compromiso de la

clave privada –por lo que la firma no habrá sido realizada por el firmante–, o si puede ser
reproducible (es decir, se pueden realizar ataques por fuerza bruta para crear firmas). Un tipo
específico de firma electrónica avanzada es la reconocida.
Una firma electrónica reconocida es una firma electrónica avanzada basada en un certificado
reconocido y generada mediante un dispositivo seguro de creación de firma. Se equipara por
completo a la firma manuscrita.
1.3.1. El Formato de la Firma Electrónica
Las normas EN 319 122 (CAdES) y EN 319 132 (XAdES) definen los formatos técnicos de la firma
electrónica. La primera se basa en el formato CMS usando sintaxis ASN.1 y la segunda usando
sintaxis y formato XML.
Bajo estas normas se definen tres modalidades de firma:
• Firma básica. Incluye el resultado de operación de hash y clave privada, identificando los
algoritmos utilizados y el certificado asociado a la clave privada del firmante.
• Firma fechada. A la firma básica se añade un sello de tiempo calculado a partir del hash
del documento firmado por una TSA (Time Stamping Authority).
• Firma validada o firma completa. Es la firma avanzada ejecutada con un DSCF (dispositivo
seguro de creación de firma) y amparada por un certificado reconocido. A la firma fechada
se añade información sobre la validez del certificado procedente de una consulta de CRL o
de OCSP realizada a la Autoridad de Certificación.
La firma completa libera al receptor de la firma del problema de ubicar al Prestador de Servicios de
Certificación y determinar los procedimientos de validación disponibles.
2. Certificados digitales
En el año 1976 los matemáticos Whitfield Diffie y Martin Hellman idearon el sistema criptográfico
de clave asimétrica, también conocido como Sistema de Clave Pública.
El sistema cuenta con dos tipos de claves:
• Pública: Es la clave que comparte el propietario de la pareja de claves. Los receptores de

dicha clave la utilizarán para cifrar y descifrar.
• Privada: Ésta clave solo la posee el emisor, nunca la transmite y sólo es utilizada por él
tanto para cifrar como para descifrar.
El sistema de clave pública garantiza la confidencialidad y la identidad del mensaje ya que:
• Si el emisor envía un mensaje que sólo deba leerlo el receptor, aquel cifrará el mensaje
con la clave pública del receptor. El receptor empleará su clave privada que sólo él conoce
para descifrar el mensaje. Se garantiza la confidencialidad del mensaje.
• Si el emisor envía un mensaje cifrado con su clave privada, el receptor necesita la clave
pública del emisor para descifrar el mensaje. De ésta manera el receptor tiene la garantía
de que el emisor es quien dice ser. Se garantiza la integridad, autenticación y el no repudio
del mensaje.
Los certificados electrónicos o digitales están basados en el sistema criptográfico de clave pública.
Esto quiere decir que, un Certificado Digital consta de una pareja de claves criptográficas, una
pública y una privada, creadas con un algoritmo, de forma que aquello que se cifra con una de las
claves sólo se puede descifrar con su clave pareja.
Habitualmente, un certificado digital queda almacenado como un fichero más en el sistema de

archivos de un ordenador (esto es, en formato digital), y contiene información que identifica a una
persona de forma unívoca. Los usos más comunes a que se destina son la firma electrónica, el
cifrado de información confidencial, y la autenticación electrónica.
Los certificados digitales pueden identificar y ofrecer garantías de seguridad ante organismos
públicos y privados que acepten certificados digitales, habiendo tenido que ser emitidos por
autoridades certificadoras (AC) como la FNMT. Según normativa española:
"Un certificado electrónico es un documento firmado electrónicamente por un prestador de

servicios de certificación que vincula unos datos de verificación de firma a un firmante y confirma
su identidad.” (Ley 59/2003, de 19 de diciembre, de firma electrónica).
El Certificado Digital es el único medio que permite garantizar técnica y legalmente la identidad de
una persona haciendo uso de medios telemáticos. Se trata de un requisito indispensable para que
particulares, empresas e instituciones puedan acceder los unos, y ofrecer los otros, servicios
seguros a través de Internet.
Además, el certificado digital:
• Permite la firma electrónica de documentos. El receptor de un documento firmado puede

tener la seguridad de que ese documento es el original y no ha sido manipulado, y el autor
de la firma electrónica no podrá negar la autoría de esta firma.
• Permite cifrar la información transmitida en las comunicaciones y asegurar la

confidencialidad del mismo modo que lo hace una firma digital. Solamente el destinatario
de la información podrá acceder al contenido de la misma.
• Vincula una clave pública a la identidad de una persona física y/o jurídica.
• Agiliza trámites administrativos a través de la red, en cualquier lugar y a cualquier hora.
• Es un documento digital que contiene la clave pública junto con los datos del titular, todo
ello firmado electrónicamente por una Autoridad de Certificación (CA).
La información básica que contiene un certificado es:
• La identidad que se certifica, por ejemplo, el número de DNI de un ciudadano.
• El período de validez. Es la fecha a partir de la cual el certificado no será reconocido como

válido.
• La clave pública que se certifica, que se usará directamente para comprobar documentos
firmados.
• El nombre del emisor del certificado. En general, se trata de una Autoridad de Certificación
(CA), un organismo que puede expedir certificados de clave pública. Esta autoridad,
además de ser una entidad de confianza da fe de que la clave pública pertenece a la
identidad especificada en el certificado.
El titular del certificado debe mantener bajo su poder la clave privada, ya que, si ésta es sustraída,
el sustractor podría suplantar la identidad del titular en la red. En caso de que la clave privada
fuese sustraída, el titular debe revocar el certificado digital lo antes posible, de igual modo que se
haría cuando una tarjeta de crédito es sustraída.
El formato de los Certificados Digitales está definido por el estándar internacional UIT-T X.509. De
esta forma, los certificados pueden ser leídos o escritos por aquellas aplicaciones que cumpla con
el mencionado estándar.
Algunos certificados digitales emitidos por organismos oficiales españoles son:
• Certificados Digitales del DNI electrónico, emitidos por el Cuerpo Nacional de la Policía.
Los mecanismos de autenticación y firma digital proporcionados por el DNI electrónico son
tratados ampliamente en el tema 40 de este mismo temario.
• Certificados de Sede Electrónica Administrativa, pertenecientes a diferentes órganos,

entidades y/o administraciones públicas. Emitidas por la ACCV en la Comunitat
Valenciana.
• Certificados de empleado público, emitidos por la ACCV en formato físico (tarjeta

criptográfica), sujetos a condiciones de uso, limitaciones y responsabilidades.
• Certificados de Firma de código, emitidos por CERES, sirven para garantizar la identidad
del autor de una aplicación de software en Windows firmando el código ejecutable.
2.1. Gestión de certificados
Para garantizar que las claves son auténticas y pertenecen a los emisores se requiere de un
proceso normalizado en el estándar X.509. Éste proceso lo llevan a cabo las agencias
certificadoras, llamada Autoridad de Certificación (CA), empresas que se encargan de verificar y
confirmar que el propietario de una clave es quien dice ser. También son las encargadas de
distribuir las claves públicas de los usuarios certificados.
La Autoridad de Certificación (CA) se encarga de emitir los certificados para los titulares tras
comprobar la identidad de los titulares, en un acto que requiere de la presencia física del titular y
documentos que acrediten la identificación. También puede realizar la emisión del certificado digital
a través de una Autoridad de Registro (SA), garantizando de esta manera que los datos del
certificado sean reales.
Por su parte, y después de verificar la identidad del solicitante, la CA firma con su clave privada el
certificado del solicitante, garantizando así la validez y la autenticidad del certificado.
Al crear el certificado se generan dos claves para el solicitante, la pública y la privada. La CA

proporcionará el certificado digital al solicitante y, además, no mantendrá ninguna copia de la clave
privada. Esto quiere decir que si el solicitante pierde el certificado tendrá que solicitar uno nuevo.
En cambio, la clave pública será almacenada por la CA, y estará a disposición de quien la solicite.
Todo el proceso de creación de claves sucede en el equipo del solicitante, por lo que la clave
privada siempre se almacenará en el equipo solicitante, lo cual garantiza que nadie más tenga
acceso a ella. Además, es imprescindible que todo el proceso sea llevado a cabo desde el mismo
equipo informático, es decir, todos los archivos relativos al certificado se almacenarán en el disco
duro del equipo desde el que se ha iniciado la tramitación. Por ello, no se puede cambiar de equipo
o de unidades de almacenamiento conteniendo el sistema operativo durante el procedimiento de
creación de claves.
Por otro lado, los certificados poseen fecha de emisión y de caducidad, y deben ser revocados o
renovados. Cuando la fecha de caducidad del certificado sea cercana a su expiración, el usuario
deberá solicitar su renovación. Si hubiese caducado, deberá solicitar uno nuevo.
La revocación del certificado la pueden ejercer tanto el propietario como la CA, ya sea porque los
datos del titular son incorrectos o han cambiado, porque la seguridad ha sido comprometida o bien
porque el certificado ha dejado de tener validez.
Para confiar en un certificado se debe confiar en su emisor. Esto es, si el emisor no es de

confianza, el certificado se deberá rechazar. Si por el contrario el emisor es de confianza, el
certificado es aceptado y, en consecuencia, se dará por buena la clave pública que certifica.
Algunos emisores conocidos de confianza son Verisign, ANCERT y CERES (FNMT).
2.2. La infraestructura de clave pública o PKI
Una PKI (Public Key Infrastructure) es el conjunto de software, hardware, recursos humanos,
políticas de seguridad y mecanismos que permiten la emisión y gestión de certificados digitales.
Las autoridades de certificación disponen de una plataforma (infraestructura de clave pública, PKI)
que permite generar y gestionar claves y certificados.
Una infraestructura de llave pública, por regla general, está formada por tres entidades distintas:
• La Autoridad de Registro (SA). Esta entidad se encarga de las operaciones administrativas

como la verificación de la identidad del usuario o el seguimiento de las solicitudes.
• La Autoridad de Certificación (CA). Esta entidad se encarga de las tareas de creación de

certificados o firma de las listas de revocación.
• La Autoridad de Depósito (AD). Esta entidad se encarga de la conservación segura de los

certificados.
2.3. X.509
X.509 es el estándar desarrollado por la UIT-T para infraestructuras de clave pública (PKI),
especificando los estándares para generar certificados digitales y los algoritmos de hash.
Se define en lenguaje ASN.1 y se codifica mediante DER (Distinguish Encoding Rules) o PEM
(Privacy Enhaced Mail).
3. Localización de claves públicas
No siempre es necesaria una PKI que nos valide la autoridad o integridad de un mensaje. Es
posible que solo queramos enviar un mensaje cifrado y que el destinatario solo deba descifrarlo.
En 1991, Phil Zimmerman desarrolló un programa llamado Pretty Good Privacy (PGP) con la idea
de proteger la información que quería enviar a través de Internet. Para ello se basó en el concepto
de criptografía asimétrica.
PGP es un criptosistema híbrido que combina criptografía asimétrica y simétrica, aprovechando lo

mejor de cada sistema. A diferencia de una PKI, PGP no es un sistema jerárquico donde solo
existe una autoridad con capacidad de emitir confianza, PGP se basa en el concepto del anillo de
confianza. En el anillo de confianza los usuarios deben firmar sus claves entre sí, asociando de
esa manera la clave recibida a su propietario.
De esta manera, dos usuarios que quieran intercambiar mensajes privados deberán firmar
mutuamente sus claves. Se implementa de esta manera un modelo de confianza descentralizada
en contrapartida con el modelo PKI.
Esa confianza puede surgir por amistad, cercanía con el otro usuario, etc.
Este sistema criptográfico cumple con los requisitos de Autenticidad, Integridad, Confidencialidad y
No repudio.
Existe un proyecto Open Source, basado en el sistema PGP, llamado OpenPGP. La aplicación,
GnuPG (GPG), implementa los mismos mecanismos y servicios que PGP. Al igual que PGP, GPG
cifra los mensajes usando las claves generadas por los usuarios. Los usuarios comparten las
claves entre sí o a través de los servidores de claves públicas.
3.1. Servidores de clave pública
Para enviar un mensaje seguro a alguien de confianza, se necesita conocer la clave pública del
destinatario, ya sea porque el destinatario la ha proporcionado, o porque se adquiere a través de
un servicio de clave.
Para poder acceder fácilmente a esas claves existen unos servidores dedicados a tal fin. Los
servidores de claves públicas actúan como una agenda para dichas claves, permitiendo que el
software utilice un dato concreto o “huella digital” del propietario de la clave para buscar una clave
completa y descargarla.
Hay muchos servidores de claves públicas PGP. Algunos son privados y otros son públicos, pero
por lo general comparten sus colecciones de claves entre sí. Estos servidores de claves no pueden
verificar si las claves públicas que sus usuarios publican son genuinas o falsas. Cualquiera puede
subir una clave pública a un servidor con un nombre cualquiera. Eso significa que una clave
asociada a un usuario por su nombre o dirección de correo electrónico en un servidor de claves
podría no ser su verdadera clave. Con el fin de comprobar la autenticidad de una clave pública, es
necesario confirmar la identidad del usuario original a través de un método digno de confianza
como el que establece una CA.
El método que mayor confianza nos reportaría consistiría en que el emisor de la clave pública, la
distribuiría en persona a los destinatarios. Sin embargo, éste método no es eficiente. Normalmente,
las claves se deberían distribuir por correo electrónico o algún otro medio de comunicación
electrónica, pero igualmente, sólo sería eficiente cuando tengamos unos pocos corresponsales. Si
tuviéramos muchos corresponsales sería un proceso tedioso.
Para solventar el problema de la distribución existen los servidores de claves públicas que
recolectan y distribuyen las claves públicas. Cuando un servidor recibe una clave pública, bien la
añade a la base de datos o bien la fusiona con una copia de la clave ya existente. Cuando alguien
requiere al servidor una clave pública, éste la busca en la base de datos y, si la encuentra, la envía
a quien se la haya solicitado.
Para solventar el problema de la autenticidad, PGP implementó en su versión 2.0 el concepto de

“Anillo de Confianza”.
3.2. Anillo de confianza
PGP/GPG permite utilizar una clave privada propia para autenticar la identidad del propietario de
otra clave. Esto es lo que se conoce por Anillo de Confianza o Red de confianza.
Es un concepto que proporciona una forma de distinguir entre claves auténticas y falsas. Si las
personas de un círculo de confianza firman las claves de la gente que conocen, terceros podrían
usar esas firmas para confirmar que las claves recibidas son genuinas. Al descargar la clave desde
un servidor de claves, éstas suelen incluir firmas de otras personas que afirman que es la correcta.
Teniendo confianza en alguien perteneciente al anillo de confianza de la clave a descargar,

podemos tener la certeza de que la clave descargada es de confianza. La ventaja de este proceso
de verificación es que se hace de forma descentralizada y no controlada por ninguna autoridad. La
confianza no viene dada por una empresa u organismo oficial, sino que es dada por los propios
usuarios. Una de las desventajas de este sistema es que cualquier usuario puede conocer la lista
de contactos de otro usuario, perdiéndose así privacidad.
Sin un servidor de claves, cuando un usuario, llamado Juan, quisiera firmar la clave de otro
usuario, por ejemplo, de Marta, tendría que enviar a Marta su clave pública, de manera que Marta
pueda agregar la clave pública de Juan a su anillo de confianza. Marta devolvería a Juan su clave
pública para que éste pudiera realizar el mismo proceso a la vez que distribuiría la clave de Juan
entre su anillo de confianza. De esta forma, Juan y Marta se validan entre sí mismos y validan al
otro ante sus anillos de confianza. Lo que determina la existencia de un servidor de claves es
facilitar este proceso.
En vez de almacenar el anillo de claves en sus propios equipos, Juan y Marta almacenarán sus
anillos en el servidor. De esta manera si un tercer usuario, Pedro, quien conoce personalmente a
Marta, pero no tiene todavía confianza con Juan, quisiera pertenecer al anillo de confianza de Juan
o quisiera poder enviarle un mensaje cifrado, buscaría en el servidor al usuario Juan. Podría darse
el caso de que un usuario malintencionado estuviera tratando de suplantar la identidad de Juan. En
este caso Pedro debería revisar si el anillo de confianza del usuario malintencionado está unido al
de Marta. Como Marta no ha firmado clave alguna del usuario malintencionado, en el anillo de
confianza del usuario malintencionado no aparecerá Marta y Pedro evitará descargarse la clave
pública fraudulenta.
4. Servicios de directorio
Tradicionalmente, el concepto de directorio ha estado ligado a cómo se organiza la información

almacenada. El término “Directorio” se relaciona con el esquema con el que los archivos se
organizan en una unidad de almacenamiento, desde los primeros sistemas de ficheros en papel
hasta los modernos ordenadores y sus sistemas operativos.
Un directorio es una estructura jerárquica que organiza y almacena datos acerca de elementos. Es
un tipo concreto de base de datos.
En un directorio telefónico, también conocido como guía telefónica, se almacena información

relativa a sus abonados, no solo el número telefónico, también presenta en ocasiones la dirección
física, números alternativos, números de fax, etc.
De forma similar, en un sistema informático en red, la información que está relacionada con los
recursos del sistema tales como servidores, usuarios, BBDD, impresoras, etc., se almacena en un
directorio.
Así pues, un servicio de directorio es un conjunto de aplicaciones y componentes que ofrecen

soporte para gestionar la información de un directorio.
Un Servicio de Directorio (SD) permite a los administradores almacenar, organizar y gestionar la

información sobre los usuarios y recursos de una red y el acceso a los recursos por parte de los
usuarios de dicha red. Esto significa que proporciona autenticación y autorización de usuarios,
incluso implementando perfiles móviles.
4.1. X.500
En 1988, la ITU y la ISO se unieron para desarrollar un conjunto de estándares de redes de

ordenadores sobre Servicios de Directorio llamado X.500. Se desarrolló como parte del modelo
OSI, destinado a ser usado como soporte para el estándar X.400.
Entre los protocolos que definen la norma X.500 podemos encontrar el Protocolo de Acceso al
Directorio (DAP, Directory Access Protocol), el Protocolo de Sistema de Directorio o el Protocolo
de Gestión de Enlaces operativos, entre otros.
Este estándar resultó ser complejo para su uso y costoso de implementar. Además, incorporaba
herramientas que debido a su complejidad, los usuarios de este protocolo terminaban por no usar o
usar muy poco. Debido a ello se empezó a desarrollar una versión más ligera del estándar llamada
LDAP (Lightweight Directory Access Protocol).
Dada la excelente aceptación que LDAP tuvo entre la comunidad se terminó convirtiendo en un
estándar de facto. A lo largo de la unidad haremos referencia al estándar LDAP, ya que es el que
se utiliza actualmente.
4.2. LDAP
LDAP surgió como alternativa a DAP, tratando de simplificar el protocolo anterior.
Las principales diferencias entre ellos, son:
• LDAP está basado en los protocolos TCP/IP, mientras que DAP está basado en el anterior
modelo OSI. Esto hace que LDAP requiera de menos recursos.
• LDAP elimina opciones que apenas se utilizaban en DAP. Además, LDAP es más intuitivo
y fácil de implementar.
• DAP utiliza estructuras ASN.1 para representar la información, mientras que LDAP lo hace
mediante strings.
Tanto LDAP como cualesquiera otro SD se basan en el modelo cliente-servidor.
4.3. Características de un SD
4.3.1. Dinamismo
Una de las principales características de un SD es que los datos, una vez introducidos, tienden a
ser estáticos.
Esto quiere decir que la información que almacena no se actualiza frecuentemente. Siguiendo el
símil de la guía telefónica, lo normal es que año tras año un abonado mantenga los mismos datos
de número de teléfono, dirección, etc. Si un abonado se cambia de casa o decide cambiar de
número, la compañía recoge la nueva información y la sustituye por la antigua, pero como
propagar los cambios de los abonados cada vez que surgen sería muy costoso, la compañía
telefónica solo edita la guía una vez al año con los cambios que sean oportunos.
En un SD los datos se pueden modificar en tiempo real, aunque no es habitual hacerlo ya que una
vez asignados los nombres, estos no se suelen cambiar. Al igual que sucedería con tu nombre de
pila o con tu número de teléfono.
4.3.2. Flexibilidad
La flexibilidad de un SD se basa en dos factores:
• Contenido: Los tipos de datos que almacena un SD pueden serlo de cualquier tipo. Esto
permite que la información almacenada pueda ser extendida sin dificultades, por ejemplo,
añadiendo información del usuario relativa a su situación sentimental o agregar una foto a
su perfil.
• Organización: La información está localizable de diversas maneras, incluso se pueden

hacer búsquedas aproximadas.
4.3.3. Seguridad
En un SD el administrador gestionará el acceso a los datos por parte de los usuarios en base a los
criterios de autorización definidos. Esto quiere decir, los usuarios del departamento de informática
de una empresa no podrán tener acceso a la BD que almacena los datos de las nóminas, pero los
usuarios del departamento de contabilidad sí que podrán. En cambio, el departamento de
informática podrá tener acceso a los servidores y a cualquier equipo del sistema, pero el
departamento de contabilidad no.
4.3.4. Personalización
Un SD permite la personalización de los datos que serán mostrados a cada tipo de usuario.
Por ejemplo, un usuario del Departamento de Informática podrá consultar su última nómina, pero
no podrá consultar las nóminas de sus compañeros. En cambio, un usuario del Departamento de
Contabilidad necesitará poder consultar las nóminas de todos sus compañeros.
4.4. Herramientas de un SD
En esta sección hablaremos de los usos más habituales de las herramientas de consulta un SD.
Por un lado, hay herramientas que requieren conectarse con el SD para realizar consultas sobre
recursos y usuarios y, por otro lado, hay aplicaciones que consultan un SD para validar y autorizar
usuarios. También se requiere de herramientas que permitan actualizar la información que alberga
el SD.
4.4.1. Herramienta de búsqueda
La utilidad principal de un SD es la de encontrar información. Para ello dispone de dos

herramientas básicas, una de búsqueda y otra de comparación.
• La herramienta de comparación tiene unos usos muy concretos ya que esta operación
comprueba si una entrada en concreto contiene un valor específico para un atributo dado.
El servidor contestará con True o False según el resultado de la comparación.
• La herramienta de búsqueda es mucho más potente, ya que permite realizar funciones de

comparación además de las propias de búsqueda.
Usualmente, las dos herramientas trabajan de forma complementaria.
La herramienta Search permite buscar en el directorio y obtener información de las entradas.

Dispone de ocho parámetros que son:
• Base. Define desde que objeto o entrada se empezará la búsqueda.
• Scope. Define el ámbito de búsqueda. Dispone de tres valores:
Onelevel: Define la búsqueda para el siguiente nivel definido en el parámetro inicial.
Sub: Define la búsqueda para todo el subárbol, desde el parámetro inicial hasta todas
sus ramificaciones.
Base: Define la búsqueda sólo en la propia base.
• Alias deferencing options. Define los alias, que sirven para enlazar las entradas del SD.
• Size limit. Define el número máximo de entradas que se quiere obtener de una búsqueda.
• Time limit. Define el tiempo máximo que la búsqueda estará en ejecución.
• Attributes-only. Este parámetro indica que la búsqueda muestre los atributos de las
entradas encontradas en vez de sus valores.
• List of attributes to return. Define la lista de atributos que se quiere obtener en una
búsqueda.
• Search filter. Define que filtros queremos aplicar a la búsqueda. Algunos ejemplos serían:
(DN=marcos). Este parámetro filtraría una búsqueda con entradas que contuvieran el
atributo “DN” (nombre distinguido) y el valor “marcos”.
(SN=per*). Este parámetro filtraría una búsqueda con entradas que contuvieran el
atributo “SN” (apellido) y valores que empiecen por “per” como: perez, peris, perea o
perales por ejemplo.
(age>=18). Este parámetro filtraría una búsqueda con entrada de usuarios mayores de
18 años.
También se pueden combinar los filtros con operadores lógicos.
4.4.2. Herramientas de gestión
Para gestionar la información de un SD disponemos de cuatro herramientas de gestión:
• Add: Esta herramienta añade una entrada nueva al directorio. El primer parámetro será el
DN, que situará la entrada en el árbol del SD, seguido de una lista con los atributos y sus
valores. Además, la lista de atributos debe coincidir con el esquema del SD.
• Delete: Esta herramienta borra una entrada del directorio. El único parámetro que requiere
es el DN de la entrada a eliminar. Si la entrada contiene hijos no se podrá borrar.
• Modify: Esta herramienta realiza cambios modificando, añadiendo y/o borrando valores de
los atributos
• Rename. Esta herramienta realiza cambios en el árbol del SD modificando el DN de las

entradas. Esto, en esencia, mueve una entrada de una rama a otra dentro del árbol.
4.4.3. Herramientas de Seguridad
La conexión a un SD no está exenta de mecanismos de seguridad. Establece mecanismos de

autenticación y autorización, debido a que es necesario que la información almacenada en un SD
sea accesible por las aplicaciones que requieran utilizarlo. Aún así, lo más probable es que las
aplicaciones solo puedan realizar consultas y sean los administradores del SD los que puedan
realizar modificaciones.
Un SD es la plataforma ideal para la distribución de certificados digitales, debido a que soluciona

dos de los principales problemas que surgen en la implementación de una Infraestructura de Clave
Pública (PKI):
• La gestión de la PKI:
Adición. Permite añadir certificados al SD y permite añadir datos del SD al certificado.
Distribución. Permite acceder y distribuir fácilmente los certificados digitales.
Revocación. Permite la revocación de un certificado con una orden de borrado al SD.
• Localización de los certificados. El SD es el lugar ideal donde almacenar certificados para

que sean accesibles por otros usuarios o aplicaciones.
4.5. Servicio de Directorio vs Base de datos
Aunque un SD sea un tipo concreto de Base de Datos (BD), hay varias diferencias a tener en
cuenta entra un SD una BD relacional:
• En una SD las operaciones de lectura de datos son de mayor frecuencia que las
operaciones de escritura.
• La estructura de organización de datos es completamente jerárquica.
• El esquema de un SD permite modificar fácilmente el diseño de las entidades que

almacena. Además, el esquema se define como clases de objeto, atributos, referencias y
nombres.
• En un SD los datos suelen ser redundantes.
• Un SD es un componente esencial en la implementación de las políticas de seguridad.
No debe confundirse un SD con el Repositorio de Directorio, siendo el Repositorio una BD

administrada por el SD que alberga información sobre los objetos de nombrado.
4.6. Servicios de Directorio vs Resolución de Nombres
Un SD tiene gran similitud con un DNS (Domain Name Server) o con un NIS (Network Information
Service), que son servicios que sirven para la resolución de nombres en la red. Ambos:
• Resuelven nombres de usuarios y equipos.
• Disponen de una BD jerárquica.
• Permite la distribución de datos de autenticación y autorización de usuarios (NIS).
En cambio, difieren en otros aspectos:
• Un DNS o un NIS están optimizados para la tarea de resolver nombres, un SD está

optimizado para propósitos generales.
• Un SD permite actualizaciones, mientras que un DNS no.
• Los DNS están orientados a transmisiones UDP, mientras que un SD suele estar orientado
a transmisiones TCP.
4.7. Funciones de un SD
Algunas de las funcionalidades que ofrece un SD son:
• Sustitución de un servicio NIS.
• Autenticación de usuarios de Sistemas Operativos, de SAMBA o de redes UNIX.
• Integración con aplicaciones de cliente de correo.
• Integración con servidores de correo electrónico.
• Integración con servidores DNS.
• Integración con servidores Web.
• Integración con PKI.
4.8. Diseño de un SD
El sistema de nombres que usa un SD permite organizar de forma jerárquica los objetos.
En este ejemplo,
Figura 1: Jerarquía de un Servicio de Directorio.
tenemos una organización (Pepito SA), donde hay dos Unidades Organizativas llamadas “usuarios”
y “servidores”. Dentro de cada OU alojamos los nombres de las aplicaciones o usuarios que se
conectarán al SD.
Esta estructura jerárquica ofrece la flexibilidad de adaptarse a multitud de entornos y situaciones.

Por ejemplo, podríamos querer agrupar a los trabajadores por departamentos:
Figura 2: Modificación de las unidades organizativas.
Cada objeto representa una entrada en el directorio. Hay un total de 11 entradas, cada una de
ellas tiene un Distinguished Name (DN). La empresa, por ejemplo, tiene dc=Pepito, dc=SA como
DN.
Para cada entrada habrá una lista de atributos, algunos atributos serán comunes en varias
entradas, en cambio otros serán específicos.
En la siguiente tabla se muestra un ejemplo de una entrada para el usuario “juan” de “contabilidad”.
Tabla I: Entrada de un objeto en el directorio
Clase del objeto Persona

cn Juan Valdés Hondarrubia
sn Valdés Hondarrubia
telephoneNumber 699632125
mail jvaldeshrubia@pepitosa.com
jpegPhoto nU6KNyVIYS817zVdf5YKF1Fr……...
La estructura de un SD mantiene el formato de Árbol de Directorio (DIT, Director Information Tree).

Partiendo de un elemento raíz, la estructura se ramifica, siendo las ramas elementos finales, o
elementos intermediarios que agrupan a otros elementos. Estos objetos normalmente son ROOT
(raíz), C (país), DC (componente de dominio) y OU (unidad organizativa). Cada objeto en el árbol
tiene un identificador único, conocido como DN (Distinguished Name).
El nivel más alto dentro del árbol será el DN Base y será lo primero que hay que definir en el DIT.
Se define mediante los DC (Domain Components), en una estructura similar al servicio DNS; de
ahí su similitud.
4.9. LDIF
LDIF (LDAP Data Interchange Format) es un estándar que define el formato en que se
representarán las entradas del directorio, sirve además para importar y exportar datos
independientemente del servidor LDAP que se esté utilizando.
Independientemente de la plataforma empleada, LDIF permite la realización de copias de

seguridad y la modificación de datos dentro del directorio.
El formato LDIF es una cadena de texto ASCII para entradas LDAP que consta de dos partes: El
DN, o Nombre Distinguido (Distinguished Name), seguido de los atributos.
No existe un orden preestablecido, pero se aconseja seguir una serie de reglas, como listar el
atributo objectclass en primer lugar para facilitar la lectura de entradas. Así, por ejemplo:
Tabla II: Presentación de una entrada del directorio
dn:uid=juan,ou=informática,ou=usuarios,o=uc3m,c=es
objectclass:person
objectclass:organizationalPerson
objectclass:account
uid:juan
sn:Valdés Hondarrubia
cn:Juan Valdés Hondarrubia
mail:jvaldeshrubia@pepitosa.com
telephoneNumber:699632125
Algunas de las reglas a tener en cuenta son:
• El atributo va a la izquierda y el valor a la derecha, separados por dos puntos (objectClass:

account).
• El primer valor de DN debe estar en la entrada LDIF por su atributo (uid:juan).
• Los atributos “objectClass” se definen en base al esquema y deben tener su

correspondiente entrada para cada valor.
• Distingue mayúsculas y minúsculas.
• Los caracteres especiales se deben escapar (\).
• En un archivo LDIF donde haya más de una entrada, cada entrada deberá ir separada por
un salto de línea.
En LDAP los atributos pueden tener valores múltiples y/o repetidos. Un ejemplo de ello es el
atributo “telephoneNumber”, que podemos tener repetido varias veces para albergar los diferentes
números de teléfono de un usuario. También es posible que algunos atributos tengan la
característica de ser únicos y no permitir más valores o múltiples entradas, como por ejemplo el
atributo “uidNumber”, que será único para cada usuario. Es el esquema el que define que valores
podemos escribir y en que atributos podremos escribirlos. Todos los esquemas definen un atributo
obligatorio llamado “objectClass.
4.10. Implementaciones de LDAP
El funcionamiento de LDAP es sencillo, y sigue estas pautas:
1. El cliente establece una conexión con el servidor LDAP. El servidor indica al cliente por el puerto
por el que está comunicándose, por defecto el 389. El servidor autenticará al cliente o bien el
cliente iniciará una sesión anónima con los parámetros por defecto.
2. El cliente efectúa las operaciones requeridas.
3. Una vez finalizadas las operaciones, cliente y servidor cierran la sesión.
Entre las implementaciones más conocidas y utilizadas tenemos:
• Active Directory, de Microsoft. Utilizado desde Windows Server 2000, es un SD donde se

almacenan todos los perfiles de usuarios, recursos de red, permisos y políticas de
seguridad. Además, permite la autenticación de usuarios dentro de una red.
• OpenLDAP, proyecto Open Source. Es una aplicación basada en el protocolo LDAP. Tiene
las mismas funcionalidades que Active Directory de Windows. Además, se ha
implementado en otras aplicaciones como: Red Hat Directory Server, Apache Directory
Server o Open DS.
5. Marcos de autenticación
Los marcos de autenticación son el conjunto de protocolos que conforman las tecnologías de
autenticación. Estas tecnologías se encargan de autenticar a los usuarios y de aplicar las políticas
de acceso al sistema o a la red. Estas tecnologías implementan:
• Almacenes de credenciales. Son los sistemas encargados de proteger y custodiar las

credenciales de los usuarios. Por ejemplo, serían almacenes un SD como Active Directory
o un sistema en la nube como una CA.
• Aplicaciones de credenciales. Son las aplicaciones que se encargan de gestionar el

proceso de autenticación, conectándose con el almacén de credenciales mediante un
protocolo designado. Siguiendo el ejemplo, la pantalla de inicio de sesión sería la
aplicación en Active Directory para el primer caso y una página web con conexión SSL
podría ser el acceso a la aplicación en la nube.
• Protocolos de autenticación. Son los estándares que definen como se realizará la

autenticación. El protocolo define los mecanismos de autenticación. En este caso, los
protocolos serían el X.500 en Active Directory y el X.509 en las conexiones SSL.
Podemos agrupar los marcos de autenticación en dos grandes categorías:
• Tecnologías delegadas de control de acceso. Algunas de estas tecnologías delegadas son

Kerberos, Radius y el estándar 802.1x.
• Tecnologías para la gestión de identidades federadas. Algunas de estas tecnologías son

OpenID, SAML, XACML y SPML.
5.1. Kerberos
Es un protocolo de autenticación de redes creado por el MIT. Se basa una arquitectura de cliente y
servidor que proporciona cifrado con autenticación mutua, es decir cliente y servidor verifican la
identidad del otro. Fue desarrollado para garantizar una comunicación segura entre dos equipos a
través de una red insegura. Emplea criptografía de clave simétrica y requiere de una tercera
entidad de confianza. Ocasionalmente puede utilizar criptografía de clave asimétrica en
determinados procesos de autenticación.
El nombre de Kerberos hace referencia al perro guardián de tres cabezas que custodiaba el Hades
en la mitología griega.
Los servicios más habituales de autenticación están basados en el factor del conocimiento, quiere
decir, en contraseñas que sólo el usuario conoce. En esta forma de autenticación, los datos
enviados no viajan encriptados, de modo que un usuario malintencionado que haya interceptado la
comunicación tendrá acceso a la contraseña y, por ende, podrá autenticarse en el servicio
fraudulentamente.
El objetivo de Kerberos es eliminar el envío de información de autenticación a través de la red.

Para ello se dispone de una infraestructura en la que participan:
• AS = Authentication Server o Servidor de autenticación.
• TGS = Ticket Granting Server o Servidor emisor de tickets.
• SS = Service Server o Servidor que alberga el servicio solicitado.
El procedimiento de autenticación para acceder al servicio solicitado es el siguiente:
• Un usuario ingresa su nombre de usuario y contraseña en la aplicación cliente (el cliente).
• El cliente genera una clave hash a partir de la contraseña y la usará como la clave secreta
del cliente.
• El cliente envía un mensaje en texto plano al AS solicitando servicio en nombre del

usuario. Ni la clave secreta ni la contraseña son enviados; solo la petición del servicio.
• El AS comprueba si el cliente está en su base de datos. Si es así, el AS genera la clave

secreta utilizando la función hash con la password del cliente encontrado en su base de
datos. Entonces envía dos mensajes al cliente:
Mensaje A: Client/TGS session key cifrada usando la clave secreta del usuario.
Mensaje B: Ticket-Granting Ticket (que incluye el ID de cliente, la dirección de red del

cliente, el período de validez y el Client/TGS session key) cifrado usando la clave
secreta del TGS.
• Una vez que el cliente ha recibido los mensajes, descifra el mensaje A para obtener el
client/TGS session key. Esta session key se usa para las posteriores comunicaciones con
el TGS. (El cliente no puede descifrar el mensaje B pues para cifrar éste se ha usado la
clave del TGS). En este momento el cliente ya se puede autenticar contra el TGS.
• Entonces el cliente envía los siguientes mensajes al TGS:
Mensaje C: Compuesto del Ticket-Granting Ticket del mensaje B y el ID del servicio

solicitado.
Mensaje D: Autenticador (compuesto por el ID de cliente y una marca de tiempo),

cifrado usando el client/TGS session key.
• Cuando recibe los mensajes anteriores, el TGS descifra el mensaje D (autenticador)

usando el client/TGS session key y envía los siguientes mensajes al cliente:
Mensaje E: Client-to-server ticket (que incluye el ID de cliente, la dirección de red del

cliente, el período de validez y una Client/Server session key) cifrado usando la clave
secreta del servicio.
Mensaje F: Client/server session key cifrada usando el client/TGS session key.
• Cuando el cliente recibe los mensajes E y F, ya tiene suficiente información para

autenticarse contra el SS. El cliente se conecta al SS y envía los siguientes mensajes:
Mensaje E del paso anterior.
Mensaje G: un nuevo Autenticador que incluye el ID de cliente, una marca de tiempo y

que está cifrado usando el client/server session key.
• El SS descifra el ticket usando su propia clave secreta y envía el siguiente mensaje al

cliente para confirmar su identidad:
Mensaje H: la marca de tiempo encontrada en el último Autenticador recibido del

cliente más uno, cifrado el client/server session key.
• El cliente descifra la confirmación usando el client/server session key y chequea si la

marca de tiempo está correctamente actualizada. Si esto es así, el cliente confiará en el
servidor y podrá comenzar a usar el servicio que este ofrece.
• A partir de este momento, el servidor provee del servicio al cliente.
Figura 3: Autenticación en Kerberos
El protocolo Kerberos presupone que el entorno en el que se realiza la autenticación no es seguro.

Se implementa Kerberos para conseguir un nivel superior de seguridad. Pese a ello Kerberos
mantiene algunas limitaciones:
• Kerberos no protege contra ataques DDoS (Denegación del Servicio por ataque
distribuido). Un usuario malintencionado podría realizar múltiples solicitudes al servidor
desde varios puntos de conexión, generando inestabilidad en el servidor, tiempos de
respuesta intolerables y finalmente consiguiendo la denegación de la comunicación con el
servidor a nuevos usuarios, con el objetivo final de que la aplicación no pueda acabar
realizando los pasos de autenticación correctamente.
• Kerberos no protege contra las vulnerabilidades asociadas a las contraseñas, como

compartir la contraseña con otra persona o usar una fecha de nacimiento propia que pueda
ser adivinada. Un usuario malintencionado podría adquirir la clave de sesión cifrada de
forma fraudulenta, por ejemplo, mediante el Man-In-The-Middle, y mediante un ataque de

diccionario o fuerza bruta podría descifrar la contraseña del usuario si está fuera
demasiado débil. El ataque Man In The Middle, o en español Hombre en el Medio, consiste
en intermediar en la comunicación entre dos equipos para que todo el tráfico de datos
entre ellas pase por nosotros de manera trasparente a ambas víctimas.
5.2. OpenID
OpenID es un protocolo de autenticación descentralizado, mediante el cual un usuario puede

autenticarse en diferentes páginas web con un único identificador en formato XRI (antes URL).
OpenID funciona proporcionando las credenciales del usuario a un sitio web que haya
implementado el protocolo. En este caso, la seguridad de la conexión recae sobre la confianza que
el usuario tenga en el sitio web. Esto impide que sea un mecanismo valido para transacciones
comerciales.
El funcionamiento de OpenID es sencillo:
• Un usuario se registra en el servicio.
• El servicio le proporciona un identificador (XRI) y una contraseña
• El usuario se identifica en los diferentes sitios usando ese identificador y esa contraseña.
Por ejemplo, Juan ha creado una cuenta en un servidor OpenID. Posteriormente Juan entra en un
sitio web que soporta el protocolo OpenID tanto para el registro como para el inicio de sesión. En
este caso, Juan quiere registrarse en el sitio. Para ello proporciona su identificador XRI en el
formulario de registro. El sitio web consultará ese identificador al servidor OpenID que especifica.
El servicio devolverá al sitio los datos de Juan. Si Juan tiene cookies almacenadas en su
ordenador el registro será automático. En caso de que no hallan cookies almacenadas al respecto,
el sitio solicitará a Juan la contraseña para verificar que es quien dice ser.
En caso de que la seguridad del equipo del usuario o del servidor fuera comprometida, toda la
relación de sitios registrado por el usuario se vería también comprometida, quedando así su
intimidad desprotegida. Debido a ello OpenID todavía es un protocolo puesto en duda.
Algunos servicios que ofrecen autenticación mediante OpenID son Flickr, WordPress, Google,
Blogger o MySpace entre otros.
6. Otras técnicas de autenticación
Los certificados y claves secretas quedan almacenados, al menos en un primer momento, en los
equipos desde los que se haya solicitado con anterioridad la emisión de un Certificado Digital. En
determinadas ocasiones es más cómodo, o incluso necesario, disponer de un dispositivo extraíble
portable que sea el que proteja la información de autenticación.
Los token (o testimonios) de seguridad son pequeños dispositivos cuya finalidad es dar soporte al
proceso de autenticación de identidad. En general se utilizan para validar la entrada a sistemas y
servicios.
Hay gran variedad de tokens. Por ejemplo, en cuanto a conexión al equipo, los más habituales son
los que se conectan al puerto USB, aunque también los hay que usan una conexión Bluetooth o
simplemente no precisan de conexión al equipo. En cuanto a capacidad de memoria y proceso,
dependerá del sistema de soporte que permita el token. He aquí cuatro casos combinando las
anteriores alternativas:
• El token guarda un valor secreto en su memoria y se comunica mediante USB con un

controlador instalado en el PC. El controlador (driver del dispositivo) sólo permite el acceso
al contenido del token tras poner un PIN correcto. En el fondo, la información que contiene
la memoria va cifrada, y es preciso que el controlador la descifre.
• El token no va conectado al ordenador, pero tiene un pequeño teclado numérico mediante

el cual el usuario introduce una coordenada proporcionada por el sistema de identificación.
El token muestra en una pequeña pantalla el valor secreto correspondiente a la
coordenada solicitada. Este ejemplo sería análogo a la tarjeta de coordenadas.
• Un tercer caso sería un token con capacidades criptográficas que pudiera responder a un
reto criptográfico mandado por el sistema de identificación, usando el método reto-
respuesta. En este caso, se contempla la modalidad de reto-respuesta usando una clave
secreta compartida o bien usando un sistema de cifrado de clave: la copia de la clave
secreta que necesita el cliente está almacenada en el token.
• Un último caso sería el de una etiqueta RFID que contiene un valor que permite identificar
la etiqueta. Dado que un lector de RFID interactúa con las etiquetas a través del espectro
electromagnético y sin usar conexiones físicas, el hecho de que la identificación sea
segura (básicamente esté protegida contra escuchas por parte de atacantes) supone un
reto importante inherente al uso de estas etiquetas en servicios y entornos que precisen
cierta seguridad.
Como técnica alternativa de autenticación posemos hacer uso de dispositivos electrónicos que
reconozcan nuestra identidad digital basándose en rasgos físicos o en aspectos personales. A
continuación, enumeramos los factores biométricos más utilizados, comentando aspectos sobre su
calidad y uso:
• Huellas dactilares: El uso de las huellas dactilares como medio de identificación tiene una
alta fiabilidad. Presenta una buena aceptación y popularidad.
• Iris: La identificación de un individuo a través del análisis del iris tiene una fiabilidad muy
alta. La desventaja que presenta respecto al anterior es su incomodidad de uso. También
resulta más complejo el análisis de la retina para identificar al individuo que el de huella
dactilar.
• Geometría de la mano: Este sistema está bastante extendido, pero presenta menor
fiabilidad que los anteriores. Además, este sistema es susceptible de padecer ataques,
puesto que no resultaría difícil recrear la forma de una mano usando un molde.
• Facciones: El análisis de la cara, ya sea en 2D o 3D, es un buen medio para identificar a

un individuo. Aun así, siempre es preferible un estudio 3D, ya que se mejoran los
resultados con respecto el mero estudio de una imagen 2D, y se dificulta el éxito de
ataques. La desventaja de los equipos 2D es que el sistema no distingue si lo que está
capturando es realmente un rostro o una fotografía de un rostro.
• Venas del dedo o la mano. El estudio vascular de los dedos o de la mano proporciona alta
fiabilidad. Además, no resulta excesivamente complejo su análisis.
• Voz: Este sistema presenta bastante fiabilidad, pero también es susceptible a los ataques.
Además, este sistema padece de poca estabilidad, con lo cual deberían ser varias las
muestras de voz analizadas para reducir la tasa de errores.
Por otro lado, disponemos de diversos protocolos y métodos de autenticación. Entre ellos se
incluyen:
• RPC seguro: Del acrónimo Remote Procedure Call. (Procedimiento de Llamada Remoto).
El RPC es un programa empleado en computación distribuida para que una máquina
pueda ejecutar código en otra máquina remota. RPC Secure, añade un mecanismo de
autenticación basado en el protocolo Diffie-Hellman.
• PAM: Del acrónimo Pluggable Authentication Module. (Módulo de autenticación

conectable). Es un mecanismo que proporciona una interfaz que permite que distintas
tecnologías de autenticación se conecten a un servicio de red a través de una aplicación
de usuario. Este mecanismo es muy utilizado en servicios FTP, Telnet o Web.
• SASL: Del acrónimo Simple Authentication and Security Layer. (Autenticación sencilla y
capa de seguridad). Es un framework que proporciona servicios de autenticación y
seguridad para diferentes protocolos de red. Entre los protocolos que emplean esta
infraestructura se encuentran IMAP, LDAP, POP3, SMTP y XMPP.
• SSH: Del acrónimo Secure Shell. (Intérprete de órdenes seguro). Es tanto el nombre del
programa que lo implementa como un protocolo de inicio de sesión remoto seguro, que
permite la comunicación cifrada entre equipos en una red no segura.
• RADIUS: Del acrónimo Remote Authentication Dial-In User Service. (Servicio de

autenticación remota de usuario por marcado). Es un protocolo de autenticación y
autorización para aplicaciones de acceso a la red. Se emplea en conexiones a ISP a través
de módem, cable-módem, DSL, Ethernet.
• DIAMETER: Es un protocolo que ofrece servicio triple A, (Authentication, Authorization,

Accounting). Es un protocolo basado en RADIUS.
Martínez-Ballesté Antoni, Solanas Agustí, Castellà-Roca Jordi. (2011). Identidad digital

(http://hdl.handle.net/10609/55582). Identificación, autenticación y control de acceso.
Universitat Oberta de Catalunya.
Martínez-Ballesté Antoni, Castellà-Roca Jordi. (2011). Identidad digital

(http://hdl.handle.net/10609/55582). Servicios de directorio. Universitat Oberta de
Catalunya.
Palazón Romero José María, Felguera Antoni, Castellà-Roca Jordi. (2011). Identidad digital
(http://hdl.handle.net/10609/55582). Single sign-on y federación de identidades. Universitat
Oberta de Catalunya.
Identidad digital:
https://www.exabyteinformatica.com/uoc/Dactiloscopia/Identidad_digital/Identidad_digital_(
Modulo_3).pdf
Distribución de claves: https://www.gnupg.org/gph/es/manual/x481.html
Servidor de clave pública: https://ssd.eff.org/es/glossary/servidor-de-clave-p%C3%BAblica,

http://www.rediris.es/cert/servicios/keyserver/
Wikipedia: Autenticación, SASL, Kerberos, Servicio_de_directorio, X.500, OpenID
Tema 40. Infraestructura de clave pública (PKI):
definición y elementos de una PKI. Prestación de
servicios de certificación públicos y privados.
Autoridades de certificación. El DNI electrónico
Javier Laguna Galindo

Colegiado 1000
La tecnología avanza a pasos agigantados y la seguridad es cada día más necesaria

en el mundo online. ¿Cómo puede una persona verificar la identidad de otra persona?
¿O cómo se puede establecer una comunicación segura en una página web para
realizar una transferencia bancaria? ¿O cómo se puede cifrar la información para que
sólo una persona pueda leerla? La respuesta a todas estas preguntas se encuentra en
los sistemas PKI o Infraestructura de Clave Pública.
Los sistemas PKI resuelven el problema inicial de transmisión de una clave sobre un
entorno todavía no seguro, para poder establecer comunicaciones posteriormente
seguras. Los sistemas de claves asimétricos permiten resolver este problema y a su
vez solucionar otros como los anteriores. Una infraestructura de clave pública es una
plataforma que soporta la gestión de certificados digitales con la finalidad de que un
usuario disponga de diversos mecanismos para proteger la información mediante los
principios de confidencialidad, integridad, autenticación y no repudio.
El principal estándar para infraestructuras de claves públicas es el X.509v3, el cual

especifica una serie de elementos que debe contener todos los sistemas, como es
Política de Seguridad, Declaración de Prácticas de Certificados (CPS), Autoridad
Certificadora (CA), Autoridad Registradora (RA), Sistema de Distribución de
Certificados y Listas de Revocación de Certificados (CRL).
En España, la ley 59/2003 regula la firma electrónica. Todas las autoridades

certificadoras emisoras de certificados digitales cumplen los detalles de la misma,
siendo la FNMT la principal en cuanto a emisión y dentro de la estructura jerárquica de
autoridades. A nivel autonómico, la ACCV es la entidad principal de certificación
emitiendo certificados, que al igual que de la FNMT son emitidos para
Administraciones Públicas. El DNI electrónico también dispone de certificados digitales
incorporados al mismo, haciendo que sea método de identificación tanto físico como
digital.
1. Infraestructura de clave pública (PKI): definición y

elementos de una PKI
Para poder mantener una comunicación cifrada, lo habitual es que uno de los extremos de la
misma establezca una clave y notifique al otro. La transmisión de la clave debe producirse en un
medio seguro, pero a su vez, si se dispone ya de un canal de comunicación seguro, no tiene
sentido enviar información cifrada por otro.
La distribución de las claves es un antiguo problema de la criptografía. Para resolver este

problema, se puede optar por el siguiente procedimiento, en el que A y B son cada uno de los
extremos de la comunicación:
• A elige una clave y la cifra con una clave que solo conoce A. El resultado lo transmite a B.
• B cifra el resultado recibido con una clave que solo B conoce. El nuevo mensaje
doblemente cifrado es transmitido a A.
• A retira su clave privada del mensaje y transmite el nuevo mensaje a B.
• B retira su clave privada del mensaje, por lo que el resultado es la clave elegida
inicialmente por A.
A pesar de haber solucionado el problema de la distribución de claves, vuelve a crearse un

problema tras las tres transmisiones producidas: ¿El mensaje recibido por cada uno de los
extremos es auténtico? ¿O ha sido transmitido por un tercero?
Para solucionar este y otros problemas, se emplea la criptografía de clave pública o también
denominada criptografía asimétrica. En ella siempre se emplean una pareja de claves: una clave
pública, conocida por todo el mundo; y otra privada, conocida únicamente por el propietario de la
misma. Este nuevo concepto dista de la criptografía tradicional, en la que tanto emisor como
receptor emplean una misma clave secreta para cifrar y descifrar los mensajes.
1.1. Sistemas criptográficos asimétricos
1.1.1. Diffie-Hellman
En 1976, Whit Diffie y Martin Hellman, de la universidad de Stanford, publicaron un método para
establecer una clave común de una manera segura a través de un canal de comunicación no
seguro. El método se basa en la exponenciación y el hecho de que los exponentes se pueden
multiplicar en cualquier orden con el mismo resultado. Parece ser que la NSA ya trabajaba con
Infraestructura de clave pública (PKI)
este concepto 10 años antes, al igual que el GCHQ, su homólogo inglés, que lo hacía desde finales
de los años 60.
El método diseñado por Diffie y Hellman era útil para el establecimiento de claves, pero no llegó a
cifrar datos. Básicamente, la idea proponía lo siguiente:
• Cada interlocutor debe disponer de dos claves, una para cifrar y otra para descifrar.
• Las dos claves deben tener la propiedad de poder invertir el efecto producido por su
pareja, pero a su vez debería ser imposible para un atacante descubrir una a partir de la
otra.
• Una de las dos claves debe ser pública para todo el mundo.
• El destinatario debe ser la única persona que conozca su clave privada y nunca ha de ser
revelada a nadie más.
El término generador sería el siguiente: dado el conjunto Ζ*p ' con p primo, diremos que α ∈ Ζ*p
es un generador de Ζ*p ' , si se cumple:
∀b ∈ Ζ*p ' ∃i tal que α i = b (1)
El enunciado del problema es el siguiente: dado un número primo p , un número α que sea un
generador de Ζ y los elementos α y α , encontrar α ab (mód p ) .
*
p'
a b
Nótese que se conoce α a y α b , pero no el valor ni a ni el de b . De hecho, si se pudieran realizar

de forma eficiente logaritmos discretos, sería suficiente con calcular a y luego (α b ) a = α ab .
Por lo tanto, suponiendo una comunicación entre A y B , en primer lugar se ha de calcular un

número primo p y un generador α de Ζ*p ' , con 2 ≤ α ≤ p − 2 . Esta información es pública y
conocida por ambos. El algoritmo por tanto es el siguiente:
• A escoge un número aleatorio x , comprendido en 1 y p − 2 y envía a B el valor

α x (mód p ) .
• B escoge un número aleatorio y , análogamente al paso anterior, y envía a A el valor

α y (mód p ) .
• B recoge α x y calcula K = (α x ) y (mód p ) .
• A recoge α y y calcula K = (α y ) x (mód p ) .
Puesto que x e y no viajan por la red, al final A y B acaban compartiendo el valor de K , sin
que nadie que capture los mensajes transmitidos pueda repetir el cálculo.
1.1.2. RSA
El algoritmo RSA debe su nombre a sus tres inventores: Ronald Rivest, Adi Shamir y Leonard
Adleman, y al estar bajo una patente, su uso comercial estuvo restringido hasta el año 2000.
A pesar de ser posiblemente el algoritmo asimétrico más sencillo de comprender e implementar,

nadie ha conseguido rebatir su seguridad. Para ello, RSA se basa en la dificultad de factorizar
grandes números, por lo que un posible atacante debería factorizar el producto de dos primos
grandes.
Para generar un par de claves ( K P , K p ) , en primer lugar se eligen aleatoriamente dos números
primos grandes, p y q , y después se calcula el producto n = pq .
Ahora se escoge un número e primo relativo con ( p − 1)(q − 1) . (e, n) será la clave pública.
Nótese que e debe tener inversa módulo ( p − 1)( q − 1) , por lo que existirá un número d tal que
de ≡ (mód ( p − 1)(q − 1)) es decir, que d es la inversa de e módulo ( p − 1)(q − 1) . (d , n) será
la clave privada. Esta inversa puede calcularse fácilmente con el Algoritmo Extendido de Euclides,
por lo que desconociendo los factores de n , el cálculo resulta prácticamente imposible.
Por lo tanto, la operación de cifrado se realiza de la siguiente forma:
c = m e (mód n) (2)
Mientras que el descifrado se hace la siguiente:
m = c d (mód n) (3)
Ya que:
c d = (m e ) d = m ed = m k ( p −1)( q −1) +1 = (m k )( p −1)( q −1) m (4)
En la práctica, para generar el par de claves RSA, se eligen p y q con un número grande de bits,
por ejemplo 512 bits, por lo que n tendrá 1024 bits. Para realizar el cifrado, se divide el mensaje en
bloque de un tamaño inferior a n, por ejemplo 1016 bits, y se realiza la codificación de cada uno. El
mensaje cifrado tendrá un tamaño un tanto mayor, pues cada bloque de 1016 bits pasará a ser de
1024 bits. En el descifrado, se parte el mensaje en bloques de 1024 bits, se aplica el algoritmo y se
tomarán los 1016 primeros bits del resultado de cada bloque.
Ejemplo:
• Elección de primos:
p = 3 y q = 11
n = p * q = 3 * 11 = 33
phi(n) = (p - 1) (q – 1) = (3 - 1) * (11 - 1) = 2 * 10 = 20
• Generación de las claves:
El exponente público será un número primo aleatorio entre 1 y phi(n). e = 7
Se calcula el exponente privado: 7 * d = 1 mod(20) => 7 * 3 = 21 => 21 mod(20) = 1 =>

d=3
Clave Pública: (n, e) = (33,7)
Clave Privada (n, d) = (33,3)
• Cifrar y descifrar:
Dato = 2
Cifrar: dato e mód (n) = 27 mód (33) = 128 mód (33) = 29 = dato _ cifrado
Descifrar: dato _ cifrado d mód (n) = 293 mód (33) = 24389 mód (33) = 2 = dato
Existen algunos puntos débiles en el algoritmo del RSA, todos ellos evitables, por lo que las
vulnerabilidades podrían evitarse.
• Claves débiles que hacen que un mensaje cifrado sea idéntico al original. Pueden ser
fácilmente evitadas.
• Claves demasiado cortas. Actualmente se considera segura una clave n de al menos 1024
bits, aunque se recomienda de 2048 bits.
• Ataques de texto claro escogido. Explotan la posibilidad de que un usuario codifique y firme
un único mensaje con el mismo par de claves.
• Ataques de módulo común. Si para crear pares de claves siempre se emplean los mismos
p y q, un atacante podría descodificar mensajes sin necesidad de la clave privada.
• Ataques de exponente bajo, cuando e es demasiado bajo.
1.2. Infraestructura de clave pública
Las Infraestructuras de Clave Pública (ICPs o PKIs, Public Key Infrastructures) están compuestas
por el conjunto de protocolos, servicios y estándares que soportan aplicaciones basadas en
criptografía de clave pública.
Se trata de un modelo de confianza basado en terceras personas, en el que los usuarios de la

infraestructura confían principalmente en dos entidades, las cuales son la base del sistema. Se
trata de la autoridad de certificación y de las autoridades de registro.
1.2.1. Funcionalidad
Una infraestructura de clave pública es una plataforma que soporta la gestión de certificados
digitales con la finalidad de que un usuario disponga de diversos mecanismos para proteger la
información mediante:
• Confidencialidad: mantener privada la información.
• Integridad: demostrar que la información no ha sido manipulada.
• Autenticación: demostrar la identidad de una persona o aplicación.
• No repudio: garantizar que no se puede rebatir la propiedad de la información.
Los principales usos de los PKI serían los siguientes:
• Identificación de usuarios y sistemas.
• Identificación del interlocutor.
• Cifrado de datos digitales.
• Firma digital de datos, tanto documentos como software.
• Asegurar las comunicaciones.
• Garantía de no repudio.
1.2.2. Componentes
Una infraestructura de Clave Pública permite implantar en modo extenso una base confiable para
la correspondencia electrónica entre usuarios que no pueden intercambiar manualmente sus
claves. Para ello, se precisa de una combinación de elementos a nivel de hardware y software,
políticas y procedimientos. La PKI se basa en identidades digitales conocidas como certificados
digitales que actúan como pasaportes electrónicos y vinculan la firma digital del usuario a su clave
pública.
La implantación de estos servicios de seguridad en redes conlleva un coste añadido, tanto en

elementos adicionales e incremento de tráfico en la red, como en requerimientos de hardware
específico o consumo de procesamiento en las entidades que participan en estos servicios.
La PKI debe constar de:
• Política de Seguridad. Establece y define la dirección de máximo nivel, así como los
procesos y principios para el uso de la criptografía. Establecerá niveles de control para la
gestión de las claves y la información valiosa.
• Declaración de Prácticas de Certificados (CPS). Imprescindible para permitir la gestión

del sistema por Autorizadores de Certificados Comerciales (CCA), detallando como
ejecutar y aplicar la Política de Seguridad. Incluye definiciones de cómo se construyen y
operan los CA, como se emiten, aceptan y revocan certificados, y como se generan,
registran y certifican las claves, dónde se almacenan y como se distribuyen a los usuarios.
• Autoridad de Certificación (CA). Entidad o servicio que emite certificados y los gestiona
durante toda su vida. Si un certificado es avalado por una CA, toda CA debe ser avalada
por otra de rango superior, hasta llegar a la cabeza de la jerarquía.
• Autoridad de Registro (RA).Entidad encargada de verificar la identidad de los solicitantes.

Dependiendo la extensión geográfica que abarque el sistema, puede ser necesario la
apertura de numerosas delegaciones distantes geográficamente para dar servicio a los
nuevos usuarios del sistema.
• Sistema de Distribución de Certificados. Dependiendo de la estructura, pueden

distribuirse de distintas formas, como por ejemplo a través de los propios usuarios o a
través de directorios dentro de una organización.
• Listas de Revocación de Certificados (CRL). Lista de certificados del sistema que han
dejado de ser válidos por algún motivo, antes de cumplirse la fecha de expiración.
Figura 1: Entidades de un sistema PKI según el RFC 5280
1.2.3. Ventajas y debilidades
Un sistema PKI lleva intrínsecas una serie de ventajas, las cuales demuestran la robustez
conceptual de los mismos. Pueden destacarse las siguientes.
• Los certificados son públicos, por lo tanto las claves no viajan a través de la red desde el
cliente hacia el servidor.
• Ofrece una mejor identificación de usuario con respecto a la autenticación por dirección IP
que puede ser dinámica o un nombre de dominio o mail al poder ser espiadas.
• La simplificación en la administración y disminución de costes.
Por otro lado, existen siempre algunas dudas en cuando a este tipo de infraestructura:
• Una CA es gestionada por personas, por lo que nunca puede confirmarse en su totalidad la
perfección del servicio.
• Si el usuario almacena la clave privada en su PC y este puede ser utilizado por otras
personas que accedan al mismo, se está comprometiendo la seguridad de la misma. Como
alternativa existen dispositivos externos que almacenan las claves.
1.2.4. Certificado digital (x509)
Un certificado digital es básicamente una clave pública y un identificador, firmados digitalmente por
una CA, que permite demostrar que la misma pertenece a un usuario concreto.
Figura 2: Esquema de una firma digital basada en funciones resumen y algoritmos de cifrado
asimétricos. A: Generación de la firma; B: verificación
El X.509 es un estándar UIT-T para infraestructuras de clave pública publicado en 1988, el cual se
encuentra actualmente en su versión X.509 v3 de la IETF (Internet Engineering Task Force), tal y
como se especifica en la RFC 5280 desde Mayo de 2008.
Las autoridades certificadoras son las entidades encargadas de emitir los certificados, los cuales
tienen una estructura concreta. A continuación se detallan los campos más relevantes de los
mismos:
• Version: Especifica la versión del protocolo X.509 con la que se ha construido el

certificado. Actualmente, lo habitual es el valor ‘3’.
• Serial Number (Número de Serie): Es un número entero positivo y único, que puede
asignar la CA y que le permitirá identificar el certificado digital. Suelen emplearse números
de módulo largo, lo que asciende a 20 octetos.
• Signature Algorithm Identifier (Identificador del Algoritmo de Firma): Este campo

contiene necesariamente el algoritmo de cifrado empleado para generar la firma del
suscriptor y necesariamente el mismo que el que se emplea en la firma de validación de la

cadena de confianza. Pueden existir extensiones opcionales, que dependerán
directamente del algoritmo de cifrado empleado.
• Issuer (Emisor): Contiene información respecto a la Autoridad de Certificación que ha

emitido el certificado digital, fundamentalmente del certificado de CA subordinada que se
ha empleado para generar el certificado final. Concretamente cuenta en su interior con los
campos Country, Organization, Organizational Unit, (departamento), State or Province
Name, Common Name, Locality; además de los opcionales de personas: Title, Surname,
Given Name, Initials, Pseudonym o Generation Qualifier.
• Validity: Vida útil del certificado y a su vez tiempo en el que se compromete la Autoridad
de Certificación a disponer de información sobre la validez del certificado.
• Subject (Suscriptor): Incluye los datos del suscriptor (o usuario final) del certificado, por lo
que va directamente asociado a la clave pública contenida en el mismo certificado. Los
campos fundamentales y de uso más extendido son: Common name, Serial number,
GivenName, SurName, Organization unit, Organization y Country.
• Subject Public Key Info: Contiene la clave pública del certificado y el algoritmo de cifrado
empleado para su generación.
Además existen una serie de extensiones, de carácter opcional, las cuales emplean los certificados
comerciales. Las más habituales son las siguientes:
• Authority Key Identifier: Identifica inequívocamente a la autoridad de certificación.
• Subject Key Identifier: Identifica inequívocamente al suscriptor.
• Key Usage: Especifica cuáles son los usos válidos para el certificado, como por ejemplo si
se puede emplear para firmar o para cifrar.
• Certificate Policies: Define la ubicación e identificación de la Política de Certificado

definida para la subordinada que ha generado el certificado.
• Basic Constraints: Incluye información muy importante como si el certificado es de CA, lo

que permitiría que el certificado se empleara para firmar otros certificados.
• CRL Distribution Points: En esta extensión se detalla la ruta del enlace donde se pueden
obtener las Listas de Revocación de Certificados (CRL) correspondientes a la subordinada
que emite el certificado final.
• Authority Information Access: E en esta extensión se mantiene la ruta de acceso al

servicio de validación OCSP (Online Certificate Status Protocol) de la CA.
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/Email=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Figura 3: Ejemplo de un certificado X.509
La sintaxis de un certificado X.509 se define empleando el lenguaje ASN.1 (Abstract Syntax

Notation One) y los formatos de codificación más comunes son DER (Distinguished Encoding
Rules) o PEM (Privacy-enhanced Electronic Mail).
Existen dos posibilidades para almacenar los certificados digitales en un archivo, bien
individualmente o bien junto a su clave privada. Los formatos de archivo de certificado más
habituales son DER binario codificado en X.509 (.der / .cer / .crt), X.509 codificado en base64
(.cer), X.509 codificado en base64 con cabeceras (.pem) y sobre todo el PKCS#7 (.p7b / .p7c). SI
por otro lado, además del certificado se precisa almacenar la clave privada, el formato de archivo
más extendido es PKCS#12 (.p12 / .pfx), el cual está protegido mediante clave simétrica.
2. Prestación de servicios de certificación públicos y

privados
2.1. Ley 59/2003, de firma electrónica
2.1.1. Introducción a la Ley
La Ley 59/2003, es la que regula jurídicamente en España el concepto de firma electrónica y

reconoce a la misma el mismo valor que la firma manuscrita sobre un documento de papel. La ley
está compuesta de 36 artículos distribuidos en 6 títulos.
En el Título 1 se introducen las Disposiciones generales, entre las que se indica que afecta a todos
los servicios de certificación establecidos en España, la validez de la firma electrónica reconocida
en todos los ámbitos y el régimen e prestación de servicios basado en el estado.
El Título 2, denominado Certificados electrónicos, inicialmente define el concepto del mismo,

detalla las características de los emitidos a personas jurídicas y la vigencia de los mismos junto a
su posible suspensión. Además se detalla el procedimiento para comprobar la identidad, las
obligaciones previas a la expedición, el contenido y la equivalencia internacional de los certificados
reconocidos. Y por último valida el documento nacional de identidad electrónico como elemento de
identificación y de firma de documentos.
El Título 3, denominado Prestación de servicios de certificación, establece las obligaciones

respecto a la protección de datos de carácter personal, a los prestadores de servicios de
certificación y a las prácticas de certificación; así como las responsabilidades y limitaciones de los
prestadores de servicios de certificación.
El Título 4, denominado Dispositivos de firma electrónica y sistemas de certificación de prestadores

de servicios de certificación y de dispositivos de firma electrónica, detalla conceptualmente los
dispositivos de creación y de verificación de firma electrónicos, los requisitos de los mismos para
lograr su certificación.
El Título 5, Supervisión y control, otorga estas funciones al Ministerio de Ciencia y Tecnología y

establece las relaciones de información y control del Ministerio con los prestadores de servicios de
certificación.
El Título 6, Infracciones y sanciones, establece el procedimiento sancionador, junto a graduaciones

sancionadoras, medidas provisionales, multas correctivas y las competencias de las mismas.
2.1.2. Prestación de servicios según la Ley
Los prestadores de servicios únicamente podrán recabar datos personales directamente de los
firmantes, siendo estos los exclusivamente necesarios y nunca para otros fines, tal y como
establece la Ley Orgánica de Protección de Datos de Carácter Personal.
Todo prestador de servicios que expida certificados electrónicos deberá cumplir las siguientes
condiciones:
• No almacenar ni copiar datos de la firma de la persona a la que presenten servicios.
• Proporcionar al solicitante antes de la expedición, información acerca de sus propias

obligaciones como propietario de la firma, mecanismos para garantizar la fiabilidad, método
para comprobar la identidad, condiciones precisas de utilización de certificado,
certificaciones obtenidas y prácticas que podrá realizar.
• Mantener un directorio actualizado de certificados en el que indicarán los certificados

expedidos, junto a su vigencia, suspensión o extinción de los mismos.
• Garantizar la disponibilidad de un servicio de consulta de vigencia de certificados

expedidos.
Todos los prestadores de servicios de certificación formularán una declaración de prácticas de

certificación en la que detallarán las obligaciones que se comprometen a cumplir en relación con la
con la gestión de los datos de creación y verificación de firma y de los certificados electrónicos, y,
en su caso la existencia de procedimientos de coordinación con los Registros públicos. Todo ello
deberá estar disponible al menos por vía telemática y gratuita, considerándose documento de
seguridad.
Los prestadores de servicios de certificación que expidan certificados reconocidos estarán

obligados a demostrar su fiabilidad, garantizar la precisión de fecha y hora de los certificados,
emplear personal cualificado, utilizar sistemas y productos fiables, tomar medidas contra la
falsificación, conservar durante 15 años la información relativa a un certificado, utilizar sistemas
fiables para almacenar certificados reconocidos y disponer de un seguro de responsabilidad civil
de 3.000.000 de euros.
Si un prestador de servicios de certificación va a cesar su actividad, deberá comunicarlo al

Ministerio de Ciencia y Tecnología y a los firmantes con una antelación mínima de 2 meses y
pudiendo optar por mantener la vigencia de los certificados a través de otro prestador de servicios
o extinguirlos.
Respecto a las responsabilidades de los prestadores de servicios de certificación, responderán por

los daños y perjuicios que causen a cualquier persona por incumplimiento de esta ley, con los
perjuicios que cause al firmante o terceros por el retraso en la inclusión en el servicio de consulta
de certificados extinguidos o suspendidos, con las personas en la que se deleguen funciones para
la prestación, así como cláusulas abusivas.
Por último, se limitará la responsabilidad de los prestadores de servicios de certificación por buena
fe, si el firmante no ha suministrado información veraz y completa de sus datos, falta de
comunicación, negligencia en la conservación de sus datos, no solicitar suspensión o revocación al
ser comprometido, usarse una vez ha expirado o superar los límites del certificado. Todo ello
también es aplicable al solicitante del certificado, en el caso de ser una empresa jurídica. Tampoco
será responsable el prestador ante casos de negligencia fehaciente del firmante e inexactitud de
los datos que consten en el certificado siempre que hayan sido acreditados por documento público.
2.2. Prestadores de servicios electrónicos de confianza
Tal y como se especifica en el artículo 30 de la Ley 59/2003, el Ministerio de Industria, Energía y

Turismo ha de publicar en su web (http://www.minetur.gob.es/telecomunicaciones/es-
es/servicios/firmaelectronica/paginas/prestadores.aspx) la información remitida por los prestadores
de servicios de confianza, con la finalidad de otorgarles la máxima difusión y reconocimiento. En
ella también está disponible el listado de prestadores no cualificados o que han cesado su
actividad.
El ministerio agrupa a los prestadores de servicios, tanto públicos como privados, según los
servicios que ofrece, por supuesto, no siendo excluyentes entre ellos. De esta forma, las
categorías empleadas son las siguientes:
• Servicio de expedición de certificados electrónicos cualificados de firma electrónica.
• Servicio de expedición de certificados electrónicos cualificados de sello electrónico.
• Servicio de expedición de certificados electrónicos cualificados de autenticación de sitios

web.
• Servicio de expedición de sellos electrónicos cualificados de tiempo.
• Servicio cualificado de entrega electrónica certificada.
• Servicio cualificado de validación de firmas electrónicas cualificadas.
• Servicio cualificado de validación de sellos electrónicos cualificados.
• Servicio cualificado de conservación de firmas electrónicas cualificadas.
• Servicio cualificado de conservación de sellos electrónicos cualificados.
3. Autoridades de certificación
Una autoridad de certificación (CA), suele tener un ámbito relativamente local, como podría ser una
empresa, una universidad o un país entero. Para verificar un certificado digital de un certificador
ajeno, del cual se desconoce su fiabilidad, existe la posibilidad de que la clave pública del propio
certificador esté a su vez firmada por otra autoridad certificadora, la cual si ofrece fiabilidad, por lo
tanto, la confianza hacia la primera CA viene propagada desde nuestra CA de confianza. Esta
circunstancia puede ser aprovechada de forma jerárquica como en las PKI, o de la forma
distribuida, como hace PGP.
3.1. Definición
Una autoridad de certificados (Certificate Authoritym, CA) es una entidad o servicio que emite
certificados. El sistema de autoridades de certificación es la base de confianza de una PKI al
encargarse de gestionar los certificados de clave pública durante toda su vida.
El problema viene al plantearse la siguiente cuestión: si la autoridad certificadora avala los datos
de los certificados, ¿Quién avala a la autoridad certificadora? Para solucionar este problema,
existen las denominadas entidades autorizadas a emitir certificados, que a su vez son avaladas por
otras de mayor confianza. O bien mediantes un sistema distribuido de validación.
3.2. Jerarquía de autoridades de certificados
En una infraestructura de autoridades certificadoras jerárquica, como es el caso de PKI, las

entidades certificadoras se organizan en forma de árbol por niveles, de tal manera que las
entidades certificadoras de un nivel poseen certificados digitales emitidos por autoridades de
niveles superiores. Se puede verificar satisfactoriamente cualquier certificado digital, si se dispone
de la clave pública de un certificador de primer nivel, los cuales son muy pocos y se encuentran
internacionalmente reconocidos.
Las entidades certificadoras finales, es decir, las que generan certificados finales a usuarios,
tendrán la responsabilidad de comprobar de manera fehaciente que cada clave pública pertenece a
su propietario. Debido a la estructura jerárquica, aquellas entidades que certifiquen a otras
entidades, deberán garantizar que estas últimas emplean los procedimientos adecuados para
identificar inequívocamente a sus usuarios. Si esto no se cumple, existiría el riesgo de la emisión
de certificados digitales falsos por parte de esta última.
Cada certificado emitido por una CA debe estar firmado por una CA de grado superior en el
esquema jerárquico, creándose así una cadena de certificados en las que unos avalan a otros
hasta llegar a la parte superior. La jerarquía de firmas y la cadena con ella formada están
contempladas en el estándar X.509 v3, que indica la forma correcta de realizar estas cadenas de
certificaciones.
Tal y como puede observarse en la Figura 4, si un usuario que dispone un certificado emitido por la
CA 3.1, quiere comprobar la identidad de uno emitido por la CA 3.3, empleará la clave pública de
CA 1, que es la primera rama común de la estructura, para verificar el certificado digital. Una vez
realizada esta comprobación, podrá confiar en CA 3.3, y en consecuencia en CA 2.2, como
certificador de la clave pública del usuario de CA 3.3.
Figura 4: Esquema jerárquico de certificación
La estructura jerárquica es un esquema sencillo y efectivo, pero en ella existe siempre un riesgo a
tener en cuenta: si una certificadora es comprometida, todos sus descendientes también se verán
comprometidos. Para mitigar este riesgo, el cual no puede desaparecer, las autoridades de
certificación están obligadas a actuar con gran transparencia y a mantener al día las listas de
revocación de certificados.
Frente a la estructura jerárquica empleada en los PKI, se puede construir un esquema distribuido
de certificación de claves o anillo de confianza, en el que todos los usuarios actúan como
autoridades de certificación. Cada usuario actuará según el grado de confianza, por lo que pueden
existir varios grados de confianza. Como puede verse, es un sistema mucho más complejo que el
jerárquico, e incluso podría llegar a ser menos confiable.
3.3. Principales autoridades de certificación
El Portal de Administración Electrónica del Gobierno de España http://firmaelectronica.gob.es,

identifica las principales autoridades de certificación españolas que emiten certificados electrónicos
para particulares y de empresa. En él, comparten relevancia tanto para particulares como para
empresas las siguientes autoridades certificadoras:
• Fábrica Nacional de Moneda y Timbre (FNMT), http://www.cert.fnmt.es/
• Agència Catalana de Certificació (CATCert), http://www.catcert.net/
• Autoritat de Certificació de la Comunitat Valenciana (ACCV), http://www.accv.es/
• IZENPE, http://www.izenpe.com/s15-12010/es/
Además de las anteriores, a nivel de autoridades relevantes a nivel de emisión de certificados para
empresa, se listan las siguientes:
• Agencia Notarial de Certificación (ANCERT), http://www.ancert.com
• ANF Autoridad de Certificación (ANF AC), https://www.anf.es
• Autoridad de Certificación de la Abogacía (ACA), http://www.acabogacia.org
• Camerfirma, http://www.camerfirma.com
• EDICOM, http://acedicom.edicomgroup.com
• Firma Profesional, https://www.firmaprofesional.com
3.4. Fábrica Nacional de Moneda y Timbre (FNMT)
La FNMT-RCM emite distintos tipos de certificados electrónicos, en función del destinatario,

pudiendo incluso solicitarse a través de su sede electrónica. Los posibles destinatarios son:
Persona física, el cual se emite de forma gratuita a todos los ciudadanos en posesión de DNI o
NIE, permitiendo identificación, firma y cifrado de documentos electrónicos.
Certificado de Representante se dividen en 3 tipos:
• Representante para Administradores únicos y solidarios, permite la verificación de firma y

la confirmación de identidad, el cual a su vez puede emitirse a administradores únicos y
solidarios debidamente inscritos en el Registro Mercantil.
• Representante de Persona Jurídica, principalmente destinado a las relaciones con las

Administraciones Públicas.
• Representante de entidad sin personalidad jurídica, destinado principalmente para trámites

tributarios.
Administración Pública, recibe certificados para los organismos públicos certificados de Empleado
público, certificados de Sede Electrónica y Sellos Electrónicos para la actuación automatizada de
la Administración Pública
Certificados de componente, para la identificación de servidores o aplicaciones informáticas,

incluyendo certificados de servidor SSL/TLS, certificados SAN, certificados wildcard, certificados
para componentes informáticos genéricos o de firma de código.
3.5. Autoritat de Certificació de la Comunitat Valenciana (ACCV)
El IVF (Instituto Valenciano de Finanzas) es el actual Prestador de Servicios de Certificación,

encargado de hacerse cumplir tanto derechos como obligaciones de todas las competencias y
funciones de la Autoritat de Certificació de la Comunitat Valenciana (ACCV).
La ACCV presta servicios tanto a ciudadanos, empresas, como administración pública. Los tipos
de certificados emitidos son los visibles en la tabla:
Tabla I: Tipos de certificados de la ACCV.C se corresponde a ciudadanos, E a empresas y AP a

Administración Pública
Tipos de certificados Funciones C E AP

Firma, cifrado e identificación en Administración Pública y
Soporte Software X
entidades privadas
Identificación en servicios telemáticos, firma electrónica y
Tarjeta Criptográfica X
cifrado de documentos y mails
Sello electrónico de Identificación en servicios telemáticos, firma electrónica y
X X
Entidad cifrado de documentos y mails
Pertenencia a empresa Identificación X X
Empleado Público Identificación X
Sede Electrónica Identificación de portal web y establecer comunicaciones
X
Administrativa seguras
Sello Electrónico de Identificación y firma de actos administrativos sin
X
Órgano intervención de la persona física competente
Servidor con soporte Identificación de portal web y establecer comunicaciones
X X
SSL seguras
Servidor con soporte Identificación de servidores y establecer comunicaciones
X X
VPN seguras vía VPN
Firma de Código Firmar el código desarrollado X X
Aplicación Firmar aplicaciones X X
Inicio de Sesión Inicio de sesión en Windows X X
Los puntos de registro están ubicados principalmente en entidades públicas como Ayuntamientos,
Universidades o Colegios Profesionales a lo largo de toda la Comunidad Valenciana, con presencia
en todas las comarcas. Además se dispone de más puntos como Murcia, Madrid o Bruselas.
4. El DNI electrónico
4.1. Definición
Tal y como declara el Art. 6 Declaración Universal de Derechos Humanos, "Todo ser humano tiene
derecho, en todas partes, al reconocimiento de su personalidad jurídica". Por tanto la identidad
personal es un derecho de todo ciudadano y los Estados tienen la obligación de establecer los
mecanismos adecuados para facilitársela. Según la definición de la Real Academia Española de la
Lengua, "La identidad es el conjunto de rasgos propios de un individuo o de una colectividad que
los caracterizan frente a los demás", y también "Conciencia que una persona tiene de ser ella
misma y distinta a las demás".
Tradicionalmente, los estados han otorgado identidad a sus ciudadanos mediante elementos
físicos, con denominaciones varias como carta de identidad, pasaporte o similares; pero en la
actualidad es necesario establecer mecanismos y procedimientos electrónicos que permitan
verificar la identidad de las personas.
A partir de esa necesidad, y teniendo en cuenta la implantación del DNI (Documento Nacional de
Identidad) tanto en la administración pública como en el sector privado, como método de
identificación único, se crea el denominado DNI electrónico. Éste, conserva la funcionalidad
tradicional, además de incorporar las nuevas tecnologías para permitir la identificación digital entre
otras tareas. Todo ello viene establecido en el artículo 2 del RD 1553/2005, de 23 de diciembre,
por el que se regula la expedición del documento nacional de identidad y sus certificados de firma
electrónica, "Dicho Documento tiene suficiente valor, por sí solo, para acreditar la identidad y los
datos personales de su titular que en él se consignen, así como la nacionalidad española del
mismo". Por supuesto, las funcionalidades incrementadas se rigen por los términos previstos en la
ya mencionada Ley 59/2003, de 19 de diciembre, de firma electrónica.
Figura 5. DNI 3.0, anverso y reverso
4.2. Funcionalidad
Tradicionalmente, el DNI ha sido reconocido por permitir la identificación de las personas. Hoy en
día incorpora nuevas funcionalidades electrónicas, en el DNI electrónico. Desde el año 2006 todos
los Documentos Nacionales de Identidad que se expiden en España son documentos electrónicos,
coexistiendo actualmente dos versiones: DNIe y DNI 3.0.
El primer DNIe, expedido desde 2006 hasta finales de 2015 incorporaba, a diferencia de su
predecesor, un chip en el anverso con información digital y se presentaba por primera vez en una
tarjeta de policarbonato con las mismas medidas que una tarjeta de crédito convencional.
Los continuos cambios en la sociedad de la información, han provocado que fuera actualizado a su
versión DNI 3.0, en el cual se incrementa la seguridad y se mejora la usabilidad del mismo al
incorporar la comunicación de forma inalámbrica a través de la tecnología NFC. Por lo tanto, se
trata de un dispositivo con Dual Interface, al permitir la lectura mediante un lector de tarjetas
inteligentes o interfaz sin contactos (contactless) para dispositivos con tecnología NFC.
El mencionado chip, contiene un certificado X509v3 de ciudadano, el cual permite autenticación y

firma, y las claves asociadas que se generaran durante el proceso de expedición y siguiendo la
legislación vigente.
4.3. Características técnicas
Dejando aparte las características propias de materiales de la tarjeta física y datos impresos,
contiene una antena NFC (Near Field Communication) para permitir la comunicación inalámbrica.
El chip del DNI electrónico está distribuido en dos zonas con diferentes niveles y condiciones de
acceso:
• Zona pública: accesible en lectura sin restricciones contiene en certificado de la CA

intermedia emisora, claves Diffie-Hellman, certificado x509 de componente, certificado de
Firma (No Repudio) y certificado de Autenticación (Digital Signature).
• Zona de seguridad: accesible en lectura por el ciudadano, en los puntos de actualización

del DNI 3.0. Contiene los datos de filiación del ciudadano (los mismo que impresos),
imagen de la fotografía, imagen de la firma manuscrita.
A continuación se detallan los 3 certificados incluidos en el DNI electrónico:
• Certificado de Componente: Permite la autenticación del DNI electrónico mediante el

protocolo de autenticación mutua definido en CWA 14890, creando un canal cifrado y
autenticado entre la tarjeta y los drivers, y no siendo accesible por los interfaces estándar
PKCS11 o similares.
• Certificado de Autenticación: Permite acreditar la identidad del ciudadano frente a

cualquiera al disponer del certificado de identidad y de la clave privada del mismo. No
habilitado en operaciones que requieran no repudio de origen, por lo que terceras personas
no tendrán garantía del compromiso. Su principal uso será generar mensajes de
autenticación y acceso seguro a sistemas informáticos.
• Certificado de Firma: Permite firmar documentos garantizando la integridad del

Documento y el No repudio de Origen. Es un certificado X509v3 estándar que tiene activo
el bit de no repudio y asociado a una par de claves pública y privada, generadas en el
interior del chip para aumentar la seguridad. Al ser expedido como certificado reconocido,
su firma tiene la misma validez legal que la manuscrita.
4.4. Seguridad
Para hacer uso del DNI electrónico, este provee de una serie de medidas de seguridad que
garantizan la integridad y evitan el robo de la información contenida en su interior.
La tarjeta dispone de distintos métodos de autenticación para demostrar la identidad de la persona:
• Autenticación de usuario: Código PIN con 3 reintentos antes de ser bloqueado. Posible
su desbloqueo mediante huella dactilar del usuario. Permite cambiar el PIN introduciendo
el PIN actual o mediante huella dactilar.
• Autenticación de usuarios mediante datos biométricos: Sólo está disponible en puntos

de acceso controlados. Si la evaluación de la huella indicada supera el umbral, la
verificación será correcta, y en caso contrario, devolverá el número de reintentos posibles.
• Autenticación de aplicación: La entidad externa demuestra tener conocimiento del

nombre y valor de un código secreto mediante un protocolo desafío-respuesta. El mismo
desafío es ejecutado por los dos extremos y en caso de coincidir, se considerará correcta.
• Autenticación mutua: Permite que cada una de las partes (tarjeta y aplicación externa)
confíe en la otra mediante la presentación mutua de certificados y su verificación.
La tarjeta DNI 3.0 permite la posibilidad de establecer un canal seguro entre el terminal y la tarjeta
que securice los mensajes transmitidos. Para ello es necesaria la autenticación previa del terminal
y la tarjeta mediante el uso de certificados.
Respecto a su funcionalidad a nivel criptográfico, es capaz de generar y gestionar claves RSA,

hash de datos con el algoritmo SHA-256 en la tarjeta o externamente, y capacidad de realización
de firmas electrónicas.
También es posible la operación de intercambio de claves es usada para compartir claves

simétricas o de sesión entre dos entidades.
La tarjeta puede realizar operaciones 3 DES con clave de 24 bytes, la cual debe ser cargada en
memoria protegiéndolo con el algoritmo RSA.
Uno de los principales usos es la realización de firma electrónica, para la cual pueden emplearse
numerosas aplicaciones que accedan mediante los módulos del PKSC#11 y que proporcionen una
interfaz estándar de acceso a la tarjeta. En el caso de la interfaz sin contactos, deberá tener
instalada una APP específica.
Para el correcto y seguro funcionamiento de la tarjeta DNI 3.0 se ha de utilizar los módulos
criptográficos CardModule y PKCS#11, que se encuentran en la página oficial
http://www.dnielectronico.es. Se encuentran disponibles para los diversos sistemas operativos.
(1) Ley 59/2003, de 19 de diciembre de 2003, de firma electrónica. Pags 45329-45353. Boletín
Oficial del estado.
(2) Margaret, Lynn. (2013). Public Key Cryptography: Applications and Attacks. Melbourne: Wiley-
IEEE Press.
(3) Stamp, M. (2005). Information Security Principles and Practice, 2nd Edition. San Jose: Wiley-
Interscience.
(4) Lucena, M. J. (2015). Criptografía y Seguridad en Computadores. Jaén.
(5) Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. y Polk, W. (2008). RFC 5280:
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile. IETF.
(6) García, E., López, M. A. y Ortega, J. J. (2005). Una introducción a la criptografía. Cuenca:
Universidad de Castilla-La Mancha.
(7) CERES - FNMT. http://www.cert.fnmt.es/
(8) Agencia de Tecnología y Certificación Electrónica (Generalitat Valenciana). http://www.accv.es/
(9) DNI electrónico – Cuerpo Nacional de Policía. https://www.dnielectronico.es

share-COIICV Temario 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

share-COIICV Temario 2

Cargado por

Copyright:

Formatos disponibles

TEMARIO PARA OPOSICIONES VOL. 2 (T.

CUERPO SUPERIOR TÉCNICO

Primera edición: junio de 2019

© Colegio Oficial de Ingeniería Informática de la Comunidad Valenciana

Todos los derechos reservados. Se autoriza el uso y consulta de esta obra

Tema 22. Virtualización de sistemas. Servidores de datos y de aplicaciones. Sistemas de

Tema 23. Tratamiento de información multimedia.

Tema 24. Arquitecturas de sistemas de información. El procesamiento cooperativo y la arquitectura

Tema 25. Arquitectura SOA.

Tema 30. Herramientas de generación de código gvNIX y gvHIDRA.

Tema 33. E-learning: Conceptos, herramientas, implantación y normalización.

TEMARIO OPOSICIONES COIICV I

Tema 35. Infraestructuras de datos espaciales. Definición y componentes. Legislaciones vigentes

Tema 39. Servicios de autenticación. Certificados digitales. Localización de claves públicas.

II TEMARIO OPOSICIONES COIICV

José Miguel Sánchez Vallés

El aumento de la cantidad de información que producen los sistemas de información,

Cloud Computing es un nuevo paradigma que incluye una nueva concepción

El Cloud computing está basado en la virtualización de recursos en internet. Algunas

El Cloud computing proporciona tanto beneficios económicos, como Tecnológicos así

Existen tres tipos principales de tipos de servicios proporcionados por el Cloud

TEMARIO OPOSICIONES COIICV | TEMA 21 1

que necesiten adaptar sus recursos de procesamiento y almacenamiento de una

En la actualidad las posibilidades que presenta Cloud computing están siendo

La globalización y las deslocalización de las grandes empresas, así como el aumento de la

Con la democratización de Internet, ha sido posible la aparición de muchos paradigmas cuya

2 TEMARIO OPOSICIONES COIICV | TEMA 21

Entre estos recursos se pueden encontrar grandes computadoras, sistemas de almacenamiento,

TEMARIO OPOSICIONES COIICV | TEMA 21 3

preocuparse por poseer la capacidad suficiente para almacenar información o de computación en

2.1. Características del Cloud Computing

Se definen algunas de sus características más importantes:

• Abstracción: La abstracción corresponde a olvidar los detalles de la implementación por

• Agilidad en la escalabilidad: Característica o capacidad consistente en aumentar o

4 TEMARIO OPOSICIONES COIICV | TEMA 21

• Autoservicio bajo demanda: permite al usuario acceder de manera flexible a las

• Acceso sin restricciones: Característica consistente en la posibilidad ofrecida a los

• Rápida elasticidad: las capacidades se pueden suministrar de manera rápida y elástica,

2.2. Ventajas del Cloud Computing

TEMARIO OPOSICIONES COIICV | TEMA 21 5

2.2.1. Beneficios económicos

Reducción de costes de mantenimiento: El Cloud Computing permite reducir los costes de

2.2.2. Beneficios Tecnológicos

Facilita el despliegue en la implantación, no es necesario infraestructura (hardware, software y

Los aspectos de seguridad de la información se ven facilitados al realizar una gestión

La responsabilidad en el desarrollo y operación de los sistemas de información puede transferirse

6 TEMARIO OPOSICIONES COIICV | TEMA 21

2.2.3. Beneficios Organizativos

Disminuye la dimensión y la orientación del departamento de TI así como la necesidad de

Debido a la estandarización y factores relacionados con la difusión de la tecnología y el empleo

2.3. Desventajas del Cloud Computing

2.3.1. Aspectos tecnológicos

La seguridad es un aspecto importante para la mayoría de las empresas. Se entiende que se va a

También se presentan temores respecto a las siguientes circunstancias:

TEMARIO OPOSICIONES COIICV | TEMA 21 7

• No se tiene control ante incidentes informáticos de diversa índole sobre la Integridad de la

• Situación de “cautividad” respecto de los proveedores de servicios Cloud por varias

• Disminución de la libertad y creatividad para introducir mejoras y personalizaciones en

• No se dispone de métricas que permitan evaluar los parámetros de calidad de servicio y

2.3.2. Aspectos organizativos

En este bloque se consideran aquellos inconvenientes en el ámbito organizativo que son

La dependencia del proveedor originada por la centralización de las aplicaciones y el

8 TEMARIO OPOSICIONES COIICV | TEMA 21