Temario Cuerpo de Gestión de Sistemas e Informática de La Admini

â
Temario Técnico
Cuerpo de Gestión de
Sistemas e Informática de la
Administración del Estado
PROMOCIÓN INTERNA
FORMA DE ACCESO "T"
Anexo a la edición 1
Preparación de oposiciones TIC

Tecnologías de la Información y Comunicaciones
ISBN 84-95679-44-2 www.manuscritos.com

Presentación
Este anexo contiene los temas del programa técnico (Bloque I, Bloque II, Bloque III y
Bloque IV) de las oposiciones de promoción interna para el Cuerpo de Gestión de Sistemas
e Informática de la Administración del Estado para la forma de acceso T, es decir, personal
proveniente de las siguientes escalas:
C. Técnicos Auxiliares de Informática de la Administración del Estado.
E. Operadores Ordenador Informática de la Administración de la Seguridad Social.
E. Administrativa, a extinguir, de la Administración de la Seguridad Social.
Plazas Operadores Ordenador, a extinguir ISM.
E. Programadores del CEDEX.
, tal y como apareció en la convocatoria publicada en el Boletín Oficial del Estado del día
16 de abril de 2003 que no fueron incluidos en la edición 01 del temario.
Temario Oposiciones TIC 1 Presentación anexo promoción interna

Contenido de la presente edición
Los temas contenidos en este anexo son los siguientes:

Bloque I
I.II.5.- Lenguajes de marca o etiqueta. Características y funcionalidades. SGML, HTML, XML
y sus derivaciones.
Bloque II
II.II.1.- Modelización conceptual. Elementos: entidades, atributos, relaciones,
identificadores, roles. Reglas de modelización. Validación y construcción de modelos de
datos
II.II.2.- Técnicas de evaluación de alternativas y análisis de viabilidad. Personal,
procedimientos, datos, software y hardware. Criterios.
II.II.10.- Diseño orientado a objetos. Concepto. Elementos: objetos, clases, herencia,
métodos. Ventajas e inconvenientes. El lenguaje de modelización unificado (UML). El
modelo CORBA.
Bloque III
III.II.1.- Estructura y organización de un departamento de sistemas de información.
Alternativas. Roles y responsabilidades. Segregación de tareas.
III.II.4.- Los lenguajes de control de trabajos: Concepto, estructura, elementos y
funcionalidades. Las técnicas y herramientas de operación automática.
III.II.9.- Documática. Archivo electrónico de documentos. Organización funcional de los
sistemas documáticos. Optimización de consultas y recuperación de la información.
Bloque IV
IV.II. 3.- La seguridad en redes. Control de accesos. Técnicas criptográficas. Mecanismos
de firma digital. Intrusiones. Cortafuegos.
Marzo 2004
C/Luna 6
28691, Villanueva de la Cañada
Tel./fax. : 91 815 54 79
http://www.grupoabantos.com
info@grupoabantos.com
Temario Oposiciones TIC 2 Presentación anexo promoción interna

Tema I.II.5. Lenguajes de marca o etiqueta. Características y
funcionalidades. SGML, HTML, XML y sus derivaciones.
Índice
1.- LENGUAJES DE MARCA O ETIQUETA. CARACTERÍSTICAS Y FUNCIONALIDADES 2
1.1 Características 2
1.2 Funcionalidades 2
2.- SGML, HTML Y XML. 3
2.1 SGML 3
2.2 HTML 3
2.2.1 Funcionalidad 4
2.2.2 Tags o tipos de marcas 4
2.2.3 Estructura de un documento HTML 5
2.2.4 Enlaces ("links") y tipos de enlaces 6
2.2.5 Edición de HTML 7
2.2.5.1 Editores de HTML 7
2.2.5.2 Editores de texto preparados para escribir HTML 8
2.2.6 HTML 4.0 8
2.2.6.1 Caracteres 8
2.2.6.2 Accesibilidad 9
2.2.6.3 Object 9
2.2.6.4 Hojas de estilo 9
2.2.6.5 Tablas 10
2.2.6.6 Formularios 10
2.2.6.7 Script 11
2.2.6.8 Impresión 11
2.2.6.9 Modificación de los elementos respecto a HTML 3.2 11
2.3 XML 11
2.3.1 Objetivos 12
2.3.2 Ventajas 12
2.3.3 Estructura del XML 12
2.3.3.1 DTD 12
2.3.3.2 XSL 13
2.3.3.3 XLL 13
2.3.3.4 XUA 14
2.3.4 Parser/DOM 14
2.4 Comparativa entre HTML y XML 14
2.5 Derivaciones 16
2.5.1 WML 17
2.5.2 VoML 17
2.5.3 Web Services 17
Temario Oposiciones TIC 1 Tema I.II.05

1.- Lenguajes de Marca o etiqueta. Características y
funcionalidades
Los lenguajes de marca, de marcado, de etiqueta o “markup languages” son sistemas
complejos de descripción de documentos que se pueden controlar desde cualquier editor
ASCII. Las marcas más utilizadas suelen describirse por textos descriptivos encerrados entre
signos de "menor" (<) y "mayor" (>), siendo lo más usual que existan una marca de principio
y otra de final.
1.1 Características
En los años 60, IBM intentó resolver sus problemas asociados al tratamiento de documentos
en diferentes plataformas a través de GML (Generalized markup Language).
El principal problema era que cada aplicación utilizaba sus propias marcas para describir
los diferentes elementos. Las marcas son códigos que indican a un programa cómo debe
tratar su contenido y así, si se desea que un texto aparezca con un formato determinado,
dicho texto debe ir delimitado por la correspondiente marca que indique cómo debe ser
mostrado en pantalla o impreso. Y lo mismo ocurre con todas las demás características de
cualquier texto.
Conociendo este sistema y conociendo a la perfección el sistema de marcas de cada
aplicación sería posible pasar información de un sistema a otro sin necesidad de perder el
formato indicado. La forma que IBM creó para solventar esto se basaba en tratar las
marcas como texto accesible desde cualquier sistema, texto plano, código ASCII. Y la
norma se denominó GML (General Modeling Language).
Más tarde GML pasó a manos de ISO y se convirtió en SGML (ISO 8879), Standard
Generalized Markup Language (Lenguaje de etiquetas generalizado normalizado). Esta
norma es la que se aplica desde entonces a todos los lenguajes de marcas, cuyos
ejemplos más conocidos son el HTML y XML e incluyendo otros como el RTF.
Los lenguajes de marcas no son equivalentes a los lenguajes de programación aunque se
definan igualmente como "lenguajes". Los lenguajes de marcas son sistemas complejos de
descripción de información, normalmente documentos, que si se ajustan a SGML, se
pueden controlar desde cualquier editor ASCII. Las marcas más utilizadas suelen describirse
por textos descriptivos encerrados entre signos de "menor" (<) y "mayor" (>), siendo lo más
usual que existan una marca de principio y otra de final.
1.2 Funcionalidades
Se puede decir que existen tres utilizaciones básicas de los lenguajes de marcas: los que
sirven principalmente para describir su contenido, los que sirven para definir su formato y
los que realizan las dos funciones indistintamente. Las aplicaciones de bases de datos son
buenas referencias del primer sistema, los programas de tratamiento de textos son
ejemplos típicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra más
conocida del tercer modelo.

2.- SGML, HTML y XML.
2.1 SGML
SGML es un lenguaje que permite definir otros lenguajes especificando la estructura de un
documento permitido. Esta especificación de un documento permitido en ese nuevo
lenguaje creado a partir de SGML es lo que se llama DTD (Data Type Definition) o
"definición del tipo de documento". En esta especificación se indica la sintaxis que los
distintos elementos de un documento podrían utilizar.
El SGML (Standard Generalized Markup Language) o lenguaje de etiquetado generalizado
normalizado es un lenguaje que surgió en 1985 con aplicaciones en diversos ramos. Los
lenguajes de etiquetado generalizado tienen las siguientes características principales:
Separa la estructura de su aspecto.
Las propiedades del texto se etiquetan según su función.
Facilita la generación de visualizaciones y la presentación de documentos.
El indexado se realiza sobre la estructura del documento, en texto completo.
Se facilita la independencia de los datos respecto de las aplicaciones.
SGML es muy versátil pero es de alta complejidad el nivel de programación que debe
hacerse para explotar sus funcionalidades.
El auge de Internet, sin duda, se debe a la Web. En 1989 se derivó del SGML el HTML. Éste
nuevo lenguaje evita la complejidad de SGML y facilita el enlace o la relación entre
documentos a través de “enlaces o hyperlinks”. El HTML es muy sencillo de utilizar para
elaborar documentos que deberán enlazarse y compartirse con otros sistemas. Es el primer
intento de los lenguajes de etiquetado de crear publicaciones digitales en Internet.
Aunque HTML es una excelente opción para la creación de documentos digitales, tiene un
número limitado de etiquetas y es poco flexible para su uso en grandes cantidades de
información. En 1996, aparece XML como el lenguaje que va a cubrir las deficiencias que
tiene HTML en la publicación de documentos.
2.2 HTML
HTML es un lenguaje de escritura de páginas Web. Las páginas Web pueden ser
visualizadas por el usuario mediante un tipo de aplicación llamada navegador. Podemos
decir por lo tanto que el HTML es un lenguaje usado por los navegadores para mostrar las
páginas Web al usuario, siendo hoy en día la interfaz más extendida en la red.
Este lenguaje nos permite combinar textos, sonidos e imágenes y combinarlos a nuestro
gusto. Además, y es aquí donde reside su ventaja con respecto a libros o revistas, el HTML
nos permite la introducción de referencias a otras páginas por medio de los enlaces
hipertexto.
El HTML se creó en un principio con objetivos divulgativos. No se pensó que la web llegara
a ser un área de ocio con carácter multimedia, de modo que, el HTML se creó sin dar
respuesta a todos los posibles usos que se le iba a dar y a todos los colectivos de gente
que lo utilizarían en un futuro. Sin embargo, pese a esta deficiente planificación, se han ido
incorporando modificaciones en los distintos estándares del HTML. El HTML 4.01 es el último
estándar que ha sido publicado.
Esta evolución tan anárquica del HTML ha supuesto toda una serie de inconvenientes y
deficiencias que han debido ser superados con la introducción de otras tecnologías
accesorias capaces de organizar, optimizar y automatizar el funcionamiento de las

páginas Web. Ejemplos de estas tecnologías son las hojas de estilo en cascada (CSS),
JavaScript u otros. Veremos más adelante en qué consisten algunas de ellas.
Otros de los problemas que han acompañado al HTML es la diversidad de navegadores
presentes en el mercado los cuales no son capaces de interpretar un mismo código de
una manera unificada. Esto obliga al Web master a, una vez creada su página,
comprobar que ésta puede ser leída satisfactoriamente por todos los navegadores, o al
menos, por los más utilizados.
2.2.1 Funcionalidad
HTML es un lenguaje para el marcado de textos e hipertextos. Este tipo de lenguajes ha
sido y sigue siendo de uso común en muchos entornos. HTML permite "marcar" un
documento para que el navegador que lo visualice sepa cómo tiene que mostrarlo. Para
ello, hace uso de las "marcas" o "tags" que formatearán el documento. Por ejemplo, para
que el navegador mostrara un texto en negrita, habría que indicarle al navegador que ese
texto ha de formatearse en negrita. Esto se conseguiría en HTML encerrando el texto en
cuestión entre las marcas correspondientes. Esto se expresa en HTML de la forma siguiente:
 Este texto se mostrará en negrita. 
Como se ve en el ejemplo anterior, una marca o "tag", no es más que una etiqueta
especial que el navegador interpreta y no muestra en el documento final, y que le indica
cómo debe formatearse el texto incluido entre el inicio del tag y el final del tag.
Como el HTML va incluido en el mismo documento, junto con el texto a formatear, hay que
seguir unas normas sintácticas para que el navegador sepa qué debe ser interpretado
como "tag" y qué debe ser texto formateado mediante los "tags". Toda marca de HTML ha
de ir encerrada entre los símbolos "< >" (menor que, mayor que). La mayoría de las marcas
deben tener una marca de apertura y otra de cierre. La marca de cierre es igual a la de
apertura con la excepción de que el "tag" ha de ir precedido por el símbolo "/". En nuestro
ejemplo anterior, el "tag" de apertura es " " mientras que el "tag" de cierre es "".
Entre el "tag" de apertura y el "tag" de cierre va incluido el texto que será formateado por
el navegador para mostrarlo en negrita en este caso. El texto se vería de la siguiente
forma:
Este texto se mostrará en negrita.
2.2.2 Tags o tipos de marcas

No todas los "tags" de HTML requieren la marca de cierre, aunque es bueno acostumbrarse
a incluirlo en todas las marcas de HTML. Estas marcas de HTML que no requieren "tag" de
cierre se denominan marcas abiertas.
Pued encontrar los "tags" de HTML incluidos en el último estándar HTML en la página del
World Wide Web Consortium http://www.w3.org/ .
Las mayúsculas o minúsculas son indiferentes al escribir las etiquetas de HTML, es decir, las
etiquetas pueden ser escritas con cualquier tipo de combinación de mayúsculas y
minúsculas. <HTML>, <html> o <HtMl> son la misma etiqueta. Resulta sin embargo
aconsejable acostumbrarse a escribirlas en minúscula ya que otras tecnologías que
pueden convivir con el HTML (XML por ejemplo) no son tan permisivas lo que puede dar
lugar a fallos o problemas de compatibilidad en el futuro.
Para que el navegador interprete un documento como documento HTML, es necesario
que este documento cumpla una serie de requisitos. La extensión del fichero indica al
navegador el tipo de documento que va a recibir. Todo documento HTML tiene que tener
como extensión .html o .htm. Esta condición es indispensable para que el navegador
interprete el documento de la manera adecuada. En internet todos los ficheros han de

tener una extensión que indique qué tipo de fichero es el que se trata de mostrar. Esta
extensión le indica al navegador qué tipo de fichero es el que recibe (tipos MIME) y en
consecuencia cómo debe tratarlo.
2.2.3 Estructura de un documento HTML

HTML es un lenguaje derivado del SGML. El World Wide Web Consortium (W3C) es una
organización que intenta estandarizar distintas tecnologías relacionadas con la Web, entre
las que se encuentra el HTML. Para conseguir que HTML sea un estándar, todos los
elementos del lenguaje HTML deben estar perfectamente definidos en el DTD (Data Type
Definition o documento de definición del tipo de datos) de dicho lenguaje.
1. Todo documento HTML debe comenzar con la orden <!DOCTYPE>. Esta orden indica al
navegador cual es el DTD a la que se ajusta el documento. Por desgracia, esta orden
no se suele utilizar ya que hay muchas personas que ignoran la relación entre HTML y
SGML. Por otro lado, para la mayoría de los navegadores actuales no tiene mayor
importancia que esta orden aparezca o no, ya que, por defecto, interpretarán el
documento como HTML.
2. A continuación, todo documento HTML incluirá el "tag" que indica el comienzo del
HTML y el tag de cierre <html> y </html>. Dentro de estas dos marcas, se incluirá todo el
código HTML necesario para la representación del documento.
3. Todo documento HTML tendrá 2 partes claramente diferenciadas:
1. La cabecera, , delimitada por <head> y </head> , en la que se incluye información
general sobre el documento como, por ejemplo, el título. En la cabecera del
documento se añade la meta-información correspondiente al documento. Esta
meta-información es información sobre el documento en sí y puede tener gran
importancia. Por ejemplo, los buscadores como "altavista", "Yahoo" o "Lycos"
indexan los documentos en sus bases de datos, usando la meta-información que
hay en la cabecera de sus documentos. Por tanto, es frecuente que en la
cabecera del documento junto al título del mismo haya también otra información
como pueden ser las "palabras claves" del documento, una descripción del mismo,
información sobre el autor, etc...
Debido a que la cabecera es lo primero que se carga en memoria cuando se lee
un documento HTML, en ocasiones éste es el sitio ideal para incluir funciones de
lenguajes de "scripting", como Javascript, para su posterior ejecución desde el
documento.
2. El cuerpo, flanqueado por las etiquetas <body> y </body>, en el que se incluye
toda la información que será mostrada por el navegador.
El resultado es un documento con la siguiente estructura:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
Etiquetas y contenidos del encabezado
Datos que no aparecen en nuestra página pero que son importantes para catalogarla: Titulo,
palabras clave,...
<TITLE> Titulo del documento </TITLE>
</HEAD>

<BODY>
Etiquetas y contenidos del cuerpo
Parte del documento que será mostrada por el navegador: Texto e imágenes
 Este es un párrafo que será mostrado en el navegador 

 Este texto será mostrado en negrita y éste en negrita e itálica

</BODY>
</HTML>
Como se ve, el formateado de un documento HTML no es complicado aunque supone la

observación y conocimiento de ciertas normas y "tags" que hacen tediosa su labor,
especialmente para un diseñador preocupado por el aspecto estético de una página.
Para evitar esta manera tan improductiva de diseñar páginas web, surgieron los editores
de HTML, como es el caso de Dreamweaver.
2.2.4 Enlaces ("links") y tipos de enlaces

En HTML, los URLs se usan para:
x Crear un vínculo a otro documento o recurso (tags A y LINK).
x Crear un vínculo a una hoja de estilo o script externos (tags LINK y SCRIPT).
x Incluir una imagen, objeto o aplicación en una página (tags IMG, OBJECT, APPLET e
INPUT).
x Crear un mapa de imágenes (tags MAP y AREA).
x Enviar un formulario (tag FORM).
x Crear un documento con marcos (tags FRAME e IFRAME).
x Citar una referencia externa (tags Q, BLOCKQUOTE, INS y DEL).
x Hacer referencia a convenciones de metadatos que describen un documento (tag
HEAD).
También puede utilizarse un enlace para determinar una imagen de fondo (tag BODY), si
bien éste es un uso que no se recomienda ya que deberían utilizarse hojas de estilo en su
lugar.
Ya hemos visto cómo el HTML se puede utilizar para el etiquetado de documentos, ahora
bien, si el HTML no tuviera más capacidad que ésta no habría tenido el avance tan
espectacular que ha tenido en estos años, ni sería la solución ideal para presentar
documentos navegables en línea. Lo que hace del HTML el lenguaje ideal para la
presentación de documentos en la Web son dos cosas:
1. Es un lenguaje multiplataforma. Lo que hay en todo documento de texto es sencilla y
puramente TEXTO. De esta manera cualquier ordenador con el software adecuado
puede interpretar, abrir y modificar este tipo de documentos. Por tanto los documentos
HTML son multiplataforma, aspecto importantísimo para la distribución de documentos
en una red compuesta de multitud de ordenadores y plataformas distintas como es
Internet.

2. Hipertexto. El hipertexto es la capacidad de este lenguaje para interrelacionar
distintos documentos, de manera que desde cualquier punto de un documento
podamos acceder a cualquier otro punto de otro documento. A través de los
hiperenlaces, "links" o simplemente enlaces que se definan en un documento,
podemos saltar a otro documento en el que se amplíe la información que estamos
viendo. De esta manera, toda la información que se podría presentar de manera
aislada en distintos documentos, se puede aunar para que sea más fácilmente
accesible.
El "tag" que permite enlazar documentos o recursos en HTML, es el "tag" <a>. A
continuación tenemos un ejemplo de lo que sería un enlace HTML:
<A HREF="http://www.grupoabantos.com"> Haz click aquí para ir a Grupo ABANTOS </A>.
Existen dos formas de referirse a la URL de un documento:
1. Absoluta: Cuando se hace referencia a la URL absoluta de un documento o
recurso, se describe el camino en su totalidad hasta ese recurso, incluyendo el
protocolo, máquina, directorio y nombre del recurso. Esa URL será la misma desde
cualquier posición de la red desde donde sea referida, o lo que es lo mismo, esa
URL irá siempre al mismo recurso, sea llamada desde donde sea llamada.
2. Relativa: Cuando se hace referencia a la URL relativa de un documento o recurso,
se describe el camino parcial que hay que seguir hasta ese recurso, tomando
como referencia el documento actual. Es decir, solo habría que describir el camino
que va desde el documento actual hasta ese otro recurso. Las URL relativas
pueden apuntar a un recurso distinto, dependiendo desde donde sean llamadas.
Ejemplo:
Tenemos un documento que se llama "tema1.htm" en el directorio "temario_tic", dentro de
la máquina asociada al dominio "www.grupoabantos.com". Tenemos otro documento
llamado "tema2.htm", en el directorio "temario_tic/bloque2" dentro de la misma máquina.
La manera de referirnos al tema2.htm, desde el tema1.htm, sería:
URL absoluta: http://www.grupoabantos.com/temario_tic/bloque2/tema2.htm
URL relativa: bloque2/tema2.htm
En la URL relativa se ha eliminado la primera parte de la URL, ya que coincide con la URL
del documento actual, por tanto sólo es necesario describir la parte de la URL que falta
hasta llegar al segundo documento.
A la hora de describir una URL relativa, sólo es necesario utilizar la misma nomenclatura
que se utiliza para navegar por distintos directorios en una máquina local. El símbolo "/" es
un directorio. El símbolo "../" es el directorio superior al actual.
2.2.5 Edición de HTML
2.2.5.1 Editores de HTML

Además del navegador necesario para ver los resultados de nuestro trabajo, necesitamos
una herramienta capaz de crear la página en sí. Un archivo HTML (una página) no es más
que un texto. Es por ello que para programar en HTML necesitamos un editor de textos.
Se puede usar un editor de textos sencillo como, por ejemplo, el Bloc de notas que viene
con Windows. Hay que tener cuidado con algunos editores más complejos como
Wordpad o Microsoft Word, pues colocan su propio código especial al guardar las páginas
con lo que podremos tener problemas.

Existen otro tipo de editores específicos para la creación de páginas web que ofrecen
muchas facilidades que nos permiten aumentar nuestra productividad. Estos editores de
HTML se encargan de traducir lo que escribimos a HTML. En el mercado existen multitud de
editores de HTML como, por ejemplo, el Dreamweaver, fabricado por Macromedia. Otras
ejemplos son editores como GoLive de Adobe o Frontpage de Microsoft.
Con el editor HTML podemos colocar imágenes, definir estilos, utilizar negritas o cursivas,
etc. sin preocuparnos de las etiquetas correspondientes a cada estilo o elemento. Es el
editor el que sabe estas etiquetas y las utiliza convenientemente. Este tipo de editores
HTML se denominan habitualmente WYSIWYG (What You See Is What You Get) porque
cuando se trabaja con ellos lo que se ve en pantalla al crear la página con el editor es lo
que se va a ver luego al visualizar la página con un navegador.
Existen dos tendencias entre las personas que se dedican a diseñar páginas Web. Por un
lado tenemos a los diseñadores que prefieren crear las páginas escribiendo directamente
en HTML y por otro los que utilizan editores HTML. Algunas diferencias entre hacerlo de un
modo u otro son las siguientes:
— Con un editor de texto plano:
Es más complicado el aprendizaje, más lento y cuando se llega a un nivel
avanzado también se hace considerablemente más difícil.
Hacer una página cuesta más trabajo y tiempo.
Dominas con mayor precisión el código de la página, queda más limpio. Si
dominas bien el HTML nunca tendrás ningún problema para hacer lo que deseas.
— Con un editor de HTML (WYSIWYG):
El aprendizaje es muy sencillo, tal como puede ser trabajar en Word.
Es muy rápido.
El código de la página tiene peor calidad, incluso puede llegar a tener errores, más
o menos visibles, que cuestan arreglar. Es la máquina la que domina el trabajo.
2.2.5.2 Editores de texto preparados para escribir HTML

Son herramientas muy interesantes para aumentar su productividad y que permiten escribir
directamenten en HTML. Se trata de unos editores de texto, como cualquier otro, que
están preparados para escribir HTML y que ofrecen multitud de ayudas a los diseñadores
como, por ejemplo:
* Colorean los códigos de las páginas para hacerlos más comprensibles.
* Ofrecen ayudas a la programación.
* Completan etiquetas.
Estos editores son por ejemplo Home Site o UltraEdit y es muy recomendable utilizarlos para
escribir las páginas de forma más fácil y productiva.
2.2.6 HTML 4.0

A continuación se enumeran las principales novedades de HMTL 4.01 respecto de HTML
3.2:
2.2.6.1 Caracteres
Se ha adoptado el juego de caracteres ISO/IEC:10646, que incluye todo tipo de carácter
en cualquier idioma. Esto significa que el W3C ha tenido en cuenta el desarrollo de la Web

a nivel mundial y que es posible insertar en una misma página idiomas o caracteres de
idiomas diferentes.
2.2.6.2 Accesibilidad
HTML 4.01 tiene en cuenta las limitaciones ante las que se encuentran las personas
discapacitadas, y, para facilitar su acceso a documentos hipertextuales, prevé
instrumentos tales como:
x Distinción entre estructura base y contenido de un documento gracias a las
hojas de estilo;
x Tablas que permiten el acceso a las personas ciegas;
x Formularios que pueden ser seleccionados mediante teclas de selección
rápida;
x Mapas "clicables" que pueden mostrar texto como alternativa a las
imágenes;
x Soporte de las marcas title y lang para todos los elementos;
x Descripciones pormenorizadas de tablas, imágenes, marcos, etc.;
x Soporte de los elementos ABBR y ACRONYM;
x Posibilidad de usar, en las hojas de estilo, lenguajes de comunicación como
tty, Braille y otros.
2.2.6.3 Object
En el HTML 4.01 se pueden insertar elementos ejecutables multimedia. Para ello, la marca
OBJECT sustituye a las marcas IMG y APPLET. Esta marca polivalente permite incluir
imágenes, vídeo, sonidos y programas de ejecución en el documento mediante una
técnica jerárquica que especifica varias opciones según el ambiente en que opera el
navegador del usuario.
2.2.6.4 Hojas de estilo

El HTML fue proyectado para gestionar páginas individuales. Si bien esto permitió la
definición de un lenguaje simple y directo, en la actualidad no responde ya a las
necesidades de sitios compuestos a menudo por miles de páginas. A ello se une el
problema de la dificultad de colocación de imágenes y texto dentro del documento con
el que se enfrentan los profesionales gráficos.
El HTML 4.0 intenta solucionar estos problemas con la adopción de las hojas de estilo, las
cuales pueden insertarse dentro de un documento de hipertexto de tres maneras distintas:
x Mediante un archivo externo;
x Mediante el encabezamiento general de cada uno de los documentos; o
bien
x Mediante la especificación de los atributos en cada una de las marcas.
El marcado HTML debe por tanto, retomar su función original de definición de la estructura
lógica del documento, dejando la gestión del diseño de página a las hojas de estilo.
Si se utilizan correctamente las hojas de estilo (archivo externo que determina el aspecto
de las páginas), es posible modificar el aspecto de diversas páginas.

Las hojas de estilo están destinadas a sustituir la costumbre, cada vez más extendida, de
los diseños de página creados mediante instrumentos inadecuados, como las tablas.
Las hojas de estilo no están escritas necesariamente en HTML. Algunos lenguajes
especializados como el CSS (Cascading Style Sheets u Hojas de Estilo en Cascada)
permiten reunir directrices de estilos procedentes de diversas fuentes, haciendo que una
prevalezca sobre la otra según las decisiones tomadas por el Web master.
2.2.6.5 Tablas
El modelo definitivo de tablas del HTML 4.01 retoma la primera redacción del HTML+. El
modelo precedente fue redactado respondiendo a los requisitos de control en la
presentación de datos que exigían las nuevas necesidades de la red.
HTML 4.01 permite un notable control de las tablas (basadas en RFC1942), que están
orientadas exclusivamente a la presentación de datos y no, como sucede actualmente, a
la definición de formatos de página.
Entre otros, se ha introducido el nuevo elemento COLGROUP que permite crear grupos de
columnas especificando alineación y tamaño.
En particular, retomando lo establecido oficialmente en el documento W3C Proposed
Recommendation, las innovaciones más importantes relativas a las tablas son:
1. Mayor flexibilidad;
2. Simplificar las tablas importadas para adecuarse al modelo SGML CALS; la última
redacción hace que el atributo sea compatible con las últimas versiones de los
navegadores más populares;
3. Posibilidad de obtener tablas desplazables con cabeceras fijas, además de un
adecuado soporte para las tablas interrumpidas durante las páginas de impresión;
4. Posibilidad de alineación para caracteres indicados como "." y ":" (por ejemplo, será
posible alinear una columna de números por el punto decimal);
5. Introducción de un nuevo elemento que permite reagrupar una serie de columnas con
anchura y propiedades de alineación diferentes por uno o más elementos;
rules="basic" ha sido sustituido por rules="groups".
2.2.6.6 Formularios
Se han introducido nuevos atributos destinados a salvar algunas lagunas de la versión HTML
3.2:
1. El atributo accesskey se encarga de especificar un acceso directo mediante el
teclado a los campos del formulario;
2. Se puede prohibir la modificación de los campos del formulario con el atributo
complementario “readonly”;
3. El elemento LABEL añade una etiqueta con un particular formulario de control.
4. El elemento FIELDSET reagrupa campos relacionados entre sí y, junto con el
elemento LEGEND, puede utilizarse para denominar el grupo. Estos dos nuevos
elementos permiten una mejor interpretación e interacción;
5. Una nueva serie de atributos onchange-INPUT, junto con el soporte para los
lenguajes script, hace que los formularios de los proveedores puedan verificar los
datos introducidos por el usuario;
6. El elemento INPUT posee un nuevo atributo accept que permite a los autores
especificar una lista de medios o tipos de estructura para el input;

7. El nuevo elemento BUTTON se puede usar para enriquecer de manera distinta los
formularios, además de los tradicionales "submit" y "reset".
2.2.6.7 Script
HTML 4.01 prevé la posibilidad de asociar lenguaje de script a los formularios, de manera
que aumente el grado de interactividad con el usuario sin tener que servirse para ello de
complejas aplicaciones java.
2.2.6.8 Impresión
HTML 4.01 permite imprimir páginas Web sin obtener por ello una mera y simple
reproducción de la página. El programador 4.01 tiene la posibilidad de definir lo que se
imprimirá y cómo se imprimirá cuando el usuario pulse la tecla "Imprimir" del navegador.
2.2.6.9 Modificación de los elementos respecto a HTML 3.2

Los nuevos elementos del HTML 4.01 son:
Q, INS, DEL, ACRONYM, LEGEND, COLGROUP, BUTTON, y FIELDSET
Los elementos que se desaconsejan son:
ISINDEX, APPLET, CENTER, FONT, BASEFONT, STRIKE, S, U, DIR, y MENU
Los elementos considerados obsoletos son:
XMP, PLAINTEXT, y LISTING
En lugar de los cuales se usará exclusivamente la marca PRE.
2.3 XML
Sus iniciales provienen de eXtensible Markup Language (lenguaje de marcas extendido o
lenguaje de marcas ampliable).
Es un lenguaje usado para estructurar información en un documento o en general en
cualquier archivo que contenga texto, como por ejemplo archivos de configuración de un
programa o una tabla de datos.
XML no es más que un conjunto de reglas para definir etiquetas (tags) semánticas que
organizan un documento en diferentes partes.
XML es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de
etiquetas estructurados.
Ha surgido como uno de los formatos de información más aceptados hoy en día, inclusive
en ocasiones es denominado "el ASCII de Internet", debido a la flexibilidad y uniformidad
con que se puede intercambiar Información, todo partiendo de un solo documento
maestro con un formato universalmente aceptado.
Es un estándar abierto y libre del consorcio W3C (http://www.w3.org ). Fue propuesto en
1996 y la primera especificación apareció en 1998. Desde entonces su uso ha tenido un
crecimiento acelerado.
Un documento XML puede ser estructurado en forma jerárquica. Debido a que XML fue
desarrollado a partir de SGML (lenguaje generalizado de marcas) eliminando un gran
número de funcionalidades que lo hacían extremadamente complejo, XML aun mantiene
una similitud con SGML.

Al igual que SGML/HTML, XML también utiliza TAGS. Sin embargo, a diferencia de HTML que
ya posee DTD's específicos, en XML es posible describir información general como
productos, descripciones, nombres, etc, con los denominados vocabularios.
2.3.1 Objetivos
XML debe ser directamente utilizable sobre Internet.
XML debe soportar una amplia variedad de aplicaciones.
XML debe ser compatible con SGML.
Debe ser fácil la escritura de programas que procesen documentos XML.
El número de características opcionales en XML debe ser mínima, idealmente cero.
Los documentos XML deben ser legibles para los humanos y razonablemente claros.
El diseño de XML debe ser preparado rápidamente.
El diseño de XML debe ser formal y conciso.
Los documentos XML deben ser de fácil creación.
La concisión en las marcas XML es de mínima importancia.
2.3.2 Ventajas
Independencia del sistema operativo y de la aplicación que lo utilice.
Se puede obligar a los autores a seguir un patrón determinado.
Puede guiar los autores a través del proceso de escritura.
Simplifica la tarea de extraer información automáticamente.
Un único documento fuente puede dar origen a varios otros formatos.
Permite separar el contenido de la forma de presentación.
Una mayor uniformidad entre documentos con el mismo DTD.
Más explícito y simple que el SGML, facilitando su análisis.
2.3.3 Estructura del XML

El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases
sintácticas y el alcance de su implementación):
2.3.3.1 DTD
El DTD (Document Type Definition o Definición del tipo de documento) es, en general, un
archivo/s que encierra una definición formal de un tipo de documento y, a la vez,
especifica la estructura lógica de cada documento. Define tanto los elementos de una
página como sus atributos.
El DTD del XML es opcional. En tareas sencillas no es necesario construir un DTD, esto se
denomina documento "bien formado"(well-formed). En otros casos es necesario un DTD y
esto se denomina documento "válido" (valid).
Un DTD es una definición exacta de la gramática de un documento, con la misión de que
se genere el código adecuado sin errores. El archivo HTML creado con el editor, al
cargarse en un navegador, es vuelto a analizar por su DTD interno para descubrir las
etiquetas correctas y las equivocadas, siempre de acuerdo a sus normas internas.

La particularidad más importante del XML es que no existen DTDs predefinidas, ya que es el
propio diseñador el que las crea según el contenido del documento, característica que
proporciona una gran facilidad de control de cualquier documento.
En la especificación de XML se describe la forma de definir DTDs particularizadas para
documentos XML, que pueden ser internas (cuando van incluidas junto al código XML) o
externas (si se encuentran en un archivo propio).
2.3.3.2 XSL
El XSL (eXtensible Stylesheet Language) define o implementa el lenguaje de estilo de los
documentos escritos para XML. Desde el verano de 1997 varias empresas informáticas
como Arbortext, Microsoft e Inso vienen trabajando en una propuesta de XSL (antes
llamado "xml-style") que presentaron a W3C.
El XSL permite modificar el aspecto de un documento. Se puede lograr múltiple columnas,
texto girado, orden de visualización de los datos de una tabla, múltiples tipos de letra con
amplia variedad en los tamaños. Este estándar está basado en el lenguaje de semántica y
especificación de estilo de documentos (DSSSL, Document Style Semantics and
Specification Language, ISO/IEC 10179) y, por otro lado, se considera más potente que las
hojas de estilo en cascada (CSS, Cascading Style Sheets), usado en un principio con el
lenguaje DHTML.
"Se espera que el CSS sea usado para visualizar simples estructuras de
documentos XML (actualmente se ha conseguido mayor integración en XML con
el protocolo CSS2 (Cascading Style Sheets, level 2) ofreciendo nuevas formas de
composición y una más rápida visualización) y que , por otra parte, XSL pueda ser
utilizado donde se requiera más potencia de diseño como en documentos XML
que encierran datos estructurados (tablas, organigramas, etc.)".
Para describir cómo se deben presentar los documentos XML podemos optar por las
mismas descripciones CSS (Cascading Style Sheets, hojas de estilo en cascada) que se
utilizan con HTML o las descripciones que se basan en XSL (Extensible Stylesheet Language,
lenguaje de hojas de estilo extensible).
CSS es una descripción del formato en el que se desea que aparezcan las entidades
definidas en un documento. Utilizar CSS con XML es similar al uso con HTML, con la
excepción de que las etiquetas son diferentes.
CSS es eficaz para describir formatos y presentaciones, pero no sirve para decidir qué tipos
de datos deben ser mostrados y cuáles no deben salir en la pantalla.
XSL no solo permite especificar cómo queremos presentar los datos de un documento XML,
sino que también sirve para filtrar los datos de acuerdo a ciertas condiciones.
Además de permitir la descripción de la presentación física, también posibilita la ejecución
de bucles, sentencias del tipo IF...THEN, selecciones por comparación, operaciones
lógicas, ordenaciones de datos, utilización de plantillas, y otras cuestiones similares.
2.3.3.3 XLL
El XLL (eXtensible Linking Language) define el modo de enlace entre diferentes enlaces. Se
considera que es un subconjunto de HyTime (Hipermedia/Timed-based structuring
Language o Lenguaje de estructuración hipermedia/basado en el tiempo, ISO 10744) y
sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificación
de texto).
Desde marzo de 1998 el W3C trabaja en los enlaces y direccionamientos del XML.
Provisionalmente se le renombró como Xlink y después tomó como nombre definitivo XLL.

Este lenguaje de enlaces extensible tiene dos importantes componentes: Xlink y el Xpointer.
Va más allá de los enlaces simples que soporta el HTML. Se podrá implementar con
enlaces extendidos. Jon Bosak establece los siguentes mecanismos hipertextuales que
soportará esta especificación:
x Denominación independiente de la ubicación.
x Enlaces que pueden ser también bidirecccionales.
x Enlaces que pueden especificarse y gestionarse desde fuera del documento a los
que se apliquen (Esto permitirá crear en un entorno intranet/extranet un banco de
datos de enlaces en los que se puede gestionar y actualizar automaticamente. No
habrá más errores del tipo "404 Not Found").
x Hiperenlaces múltiples (anillos, múltiples ventanas, etc.).
x Enlaces agrupados (múltiples orígenes).
x Transclusión (el documento destino al que apunta el enlace aparece como parte
integrante del documento orígen del enlace).
x Se pueden aplicar atributos a los enlaces (tipos de enlaces).
2.3.3.3.1 Xlink/ XPointer

XLink) define la forma en la que los documentos XML deben conectarse entre sí mientras
XPointer describe cómo se puede apuntar a un lugar específico de un determinado
documento XML.
Las especificaciones de los hipervínculos para XML permiten adherirse a cualquier
etiqueta, hacer referencia a un lugar concreto de un documento determinado a través de
su nombre o localización, ser descritos en documentos externos, ser procesados de formas
distintas, ser multifuncionales (permitir varios saltos), etc.
Al contrario de lo que ocurre con HTML, en XML existen dos tipos básicos de hipervínculos:
simples y extendidos.
2.3.3.4 XUA
El XUA (XML User Agent) es la estandarización de navegadores XML. Todavía está en
proceso de creación de borradores de trabajo. Se aplicará a los navegadores para que
compartan todos las especificaciones XML.
2.3.4 Parser/DOM
Después de recoger la información de todos los documentos que definen la información
XML, se genera internamente una estructura que organiza a los elementos que describen
las etiquetas en forma de árbol jerárquico, lo que facilita el control de dichos elementos.
2.4 Comparativa entre HTML y XML

El lenguaje HTML es originariamente un subconjunto del más completo SGML,
especializado en la descripción de documentos en pantalla a través de marcas (tags,
etiquetas).
En teoría, HTML es un subconjunto de XML especializado en presentación de documentos
para la Web, mientras que XML es un subconjunto de SGML especializado en gestión de
información para la Web.
En la práctica, HTML está un poco dentro de XML (que a su vez es parte de SGML) y otro
poco fuera de SGML.

Para reconducir esto, el grupo W3C ha dictado reglas expresas para distinguir el HTML que
sigue a al pie de la letra las normas de XML, denominándolo XHTML (eXtendible HyperText
Markup Language), que no es más que una reformulación de HTML 4 dentro de las normas
de XML.
Podemos comparar el lenguaje XML con el lenguaje HTML. A continuación tenemos un
fragmento de código HTML:
<h1>
Aula
</h1>
<ul>
<li>
Ordenador individual con pantalla plana.
El fabricante es IBM y su precio 900.
</li>
<li>
Dos teclados inalámbricos, de excelente
calidad, con un ratón inalámbrico cada una.
</li>
<li>
3 teclados convencionales.
</li>
</ul>
Y ahora un fragmento de código XML equivalente:
<aula>
<ordenador tipo="individual" pantalla="plana">
<fabricante>IBM</fabricante>
<precio>900</precio>
</ordenador>
<teclado tipo="inalambrico">
<cantidad>2</cantidad>
<calidad>excelente</calidad>
<ratón incluido="sí">
<modelo>inalámbrico</modelo>
</raton>
</teclado>
< teclado tipo="convencional”>
<cantidad>3</cantidad>
<calidad>normal</calidad>

</teclado>
</aula>
Fundamentalmente HTML está orientado a la presentación de datos, en cambio, XML está
orientado a los datos en sí mismos.
HTML es un lenguaje de presentación. Define un conjunto de etiquetas y atributos válidos,
una utilización válida de estos elementos y un significado visual para cada elemento del
lenguaje. Mientras que, XML es un metalenguaje (un lenguaje para definir otros lenguajes).
XML no define las etiquetas ni cómo se utilizan, sólo define unas pocas reglas sintácticas
para crear documentos.
La principal ventaja de XML es que cualquier programa informático trabajará mejor con
datos en XML.
Como conclusión, XML y HTML son complementarios. XML no sustituye a HTML pues sirven
para cosas distintas: HTML para presentar información en páginas Web y XML para
representar e intercambiar datos, independientemente de su presentación.
2.5 Derivaciones
A continuación se describen algunos lenguajes de marcado que son derivaciones de los
anteriormente vistos. Existen muchos más, pero aquí se han elegido los más importantes
hoy en día.
2.5.1 Lenguajes derivados de XML para Web Services
2.5.1.1 UDDI. Descubrimiento de web services.

UDDI (Universal Description, Discovery and Integration) es uno de los protocolos más
populares para Web services (servicios Web). Como su nombre indica, sirve para la
descripción, descubrimiento e integración de un modo universal. Es una plataforma
basada en XML que permite a los servicios descubrirse unos a otros, definir cómo
interactúan y compartir información en registros globales. UDDI sería necesario si se quiere
usar SOAP y publicar los modos de comunicar con los servicios.
UDDI almacena la información sobre cómo formatear un mensaje XML y cómo incluir la
información en un sobre SOAP.
2.5.1.2 WSDL. Descripción de web services

WSDL (Web Services Description Language) es el lenguaje formateado en XML que utilizan
los web services junto con UDDI para crear descripciones no sólo sobre la localización del
web service y cómo lanzarlo, sino también para incluir información de más alto nivel sobre
la lógica de negocio que engloba al web service, palabras clave asociadas al web
service, etc.
Existen otros estándares para descripción de web services basados en XML, que se
enumeran a continuación:
– WSCL (Web Services Conversation Language): lenguaje para la descripción de las
secuencias legales de mensajes en las interacciones entre web services.
– WSCM (Web Services Component Model): modelo para empaquetar los componentes
de salida de los web services.

– WSEL (Web Services Endpoint Language): lenguaje para la descripción de las
características no operacionales de los puntos finales del servicio, como la calidad de
servicio (QoS), el coste o las propiedades de seguridad.
– WSFL (Web Services Flow Language): lenguaje para describir los patrones de uso e
interacción.
2.5.1.3 SOAP. Empaquetado de mensajes

Los mensajes entre web services se escriben en XML. El método más popular para
empaquetar los mensajes XML es SOAP (Simple Object Access Protocol). SOAP incluye el
mensaje en un sobre que describe cómo procesar el mensaje y permite un modo de
codificar tipos complejos de datos que XML-RPC no puede codificar.
Una ventaja es que SOAP usa HTTP, lo que permite pasar fácilmente por los cortafuegos.
2.5.2 WML
WML es el lenguaje empleado en WAP que a su vez consiste en un protocolo que permite
el envío de datos por telefonía móvil. Da así acceso a Internet, siguiendo la arquitectura
de Cliente-Servidor.
La programación en WML hereda la mayor parte de sus construcciones sintácticas de XML.
Este es un rasgo en común con HTML. El salto entre ambos lenguajes es prácticamente
inmediato.
La DTD (Document Type Definition) que contiene todas las especificaciones sobre WML y
los anexos necesarios está disponible en las páginas de Open Mobile Alliance Ltd., la
sucesora del WAPForum (www.openmobilealliance.org/ )
2.5.3 VoML
VoiceXML es una especificación del VoiceXML Forum, un consorcio de más de 300
empresas creado en 1999 por AT&T IBM y Motorola con el objeto de estandarizar y
promover el uso de un único lenguaje diseñado para ofrecer los contenidos de Internet vía
voz . VoiceXML Forum ha dado el control sobre los futuros desarrollos del lenguaje al World
Wide Web Consortium (W3C), puesto que este lenguaje está basado en el estándar XML.
VoiceXML es un lenguaje de etiquetas que sigue las reglas sintácticas de XML con reglas
semánticas que permiten la creación de aplicaciones de voz. VoiceXML se puede utilizar
para crear páginas tanto estáticas como dinámicas ya que, al igual que HTML, se puede
embeber en programas escritos en lenguajes de programación como Java o C#.
Se trata de un lenguaje que permite la comunicación entre el hombre y la máquina de
forma hablada; es decir, es posible, por ejemplo, acceder a Internet usando simplemente
la voz. No es necesario mencionar el gran avance que esto supondría para las personas
invidentes; podrían acceder a gran parte de la información de Internet sin que su
discapacidad supusiese un impedimento para ello.
Actualmente no todo el mundo posee un ordenador, por lo que carecen de la posibilidad
de acceder a Internet. Pero lo que sí tiene casi todo el mundo es un teléfono, y con
VoiceXML es posible el acceso a Internet desde el teléfono simplemente usando la voz.
Para ello el usuario realizará una llamada al número que se ha asignado a la página,
cuando se reciba esta llamada, el navegador vocal buscará la URL en donde reside dicha
página. Según el W3C un navegador vocal es: "un dispositivo que interpreta un lenguaje
de marcas (vocales) y es capaz de generar salida por voz y/o interpretar entradas vocales
así como posiblemente otras modalidades de entradas/salidas".

Además el uso del teléfono móvil está más extendido y sus características (son pequeños,
ligeros, baratos y tienen baterías de larga duración) les hacen mucho más portátiles que
los ordenadores. Con el teléfono móvil se puede acceder a la información desde
cualquier lugar y en cualquier momento, además puede utilizarse para aplicaciones que
no es posible llevar a cabo sobre un ordenador (como los servicios basados en
localización) y cada vez son más utilizados para acceder a Internet. Por otra parte, si
tenemos en cuenta sus limitadas posibilidades (pantallas pequeñas, reducida memoria... )
a la hora de acceder a la información de Internet en modo texto, VoiceXML parece la
solución perfecta.
El acceso a Internet vía voz se realiza mediante los Portales de Voz en los que se permite
interactuar automáticamente con los clientes por medio de conversión texto a voz,
reconocimiento de voz y DTMF (pulsación de tonos). El acceso al servicio del Portal de Voz
se realiza mediante una llamada de teléfono. La plataforma funciona como elemento
intermediario, estableciendo la conexión entre el usuario que realiza la llamada y el
servicio.
Pero el acceso a Internet vía voz no es la única posibilidad que ofrece el uso de esta
tecnología, puede ser aplicada en numerosos y diversos sectores:
– Recuperación de información
– Comercio electrónico: tiene sentido sólo si el usuario ya conoce el producto o dispone
de un catálogo
– Atención al cliente
– Aplicaciones financieras: cotización de acciones, banca...
– Servicios telefónicos como marcación por voz.
– Acceso a información de los conductores
– Acceso al correo electrónico
– Aplicaciones Intranet para control de inventario, realización de pedidos...
Sin embargo hay que tener en cuenta que no todo son ventajas, ya que la voz no es como
un teclado, no se trata de un conjunto de tonos constantes y universales. Siempre se
producirán errores en el reconocimiento de la voz, en la comprensión o simplemente al
convertir la voz a texto. Además a la hora de introducir datos con la voz hay que tener en
cuenta que existen gramáticas que recogen las entradas válidas y por mucho vocabulario
que abarquen estas gramáticas siempre quedará alguna que no contemple. Por esta
razón hay que guiar claramente al usuario e indicarle cuáles son las entradas válidas, para
que no caiga en el error de creer que esto es como una película de ciencia ficción y que
puede hablar libremente porque “la máquina le entenderá”. Por estos motivos lo ideal
sería poder combinar VoiceXML con otras tecnologías (como WAP) para paliar las posibles
deficiencias de un sistema basado sólo en la voz.
Pero no sólo se presentan inconvenientes en el reconocimiento de la voz, sino también a la
hora de sintetizarla. La conversión texto a voz permite sintetizar voz a partir de textos con
una calidad muy alta, de hecho en un futuro no muy lejano se supone (algo difícil de
creer) que no se podrá distinguir una voz sintetizada de una voz pregrabada. Esto permite
emitir por la línea telefónica de forma natural información muy variada y flexible. Así, en los
nuevos sistemas de respuesta telefónica automática el llamante puede interactuar
hablando de forma natural y solicitar información muy diversa mientras que el sistema
responde con voz sintetizada. Pero la voz sintetizada no es humana, eso está claro, y esto
hace la comunicación muy impersonal, algo que no gusta a la mayoría de la gente.
¿Quién no ha dicho alguna vez “odio hablar con esas máquinas”?, y eso es precisamente
lo que se pretende con VoiceXML: hablar con las máquinas.

Así que a pesar de todas las posibilidades que ofrece VoiceXML, queda por comprobar la
aceptación que tendrá y si alcanzará las expectativas. El tiempo lo dirá.

Tema II.II.1. Modelización conceptual. Elementos: entidades,
atributos, relaciones, identificadores, roles. Reglas de
modelización. Validación y construcción de modelos
de datos.
Índice
1.- MODELIZACIÓN CONCEPTUAL. ELEMENTOS. 2
1.1 Principios del análisis 2
1.1.1 Dominio de la información 2
1.1.2 Modelado 3
1.1.3 Partición 3
1.1.4 Visiones lógicas y físicas 3
1.2 Modelado de datos 3
1.2.1 Análisis de datos 3
1.2.1.1 Abstracción 3
1.2.1.2 Etapas del análisis de datos 4
1.2.2 Modelos de datos 4
1.2.2.1 Clasificación de los modelos de datos 4
1.2.2.2 Objetos de datos, atributos y relaciones 5
1.2.2.3 Cardinalidad y modalidad 6
2.- REGLAS DE MODELIZACIÓN. VALIDACIÓN Y CONSTRUCCIÓN DE MODELOS DE DATOS. 6
2.1 El modelo Entidad/Relación (MER) 6
2.1.1 Definiciones previas 6
2.1.2 Pasos a seguir 8
2.2 Modelo Entidad/Relación extendido 8
2.2.1 Cardinalidades de un tipo de entidad. 8
2.2.2 Dependencia en existencia y en identificación 8
2.2.3 Especialización, generalización y herencia. 9
2.3 Validación de modelos de datos 11
2.4 Apéndice: Modelo Entidad/Relación extendido según Métrica v.3 14
Temario Oposiciones TIC 1 Tema II.II.01

1.- Modelización conceptual. Elementos.
1.1 Principios del análisis

Los métodos de análisis existentes tienen cada uno un conjunto de principios operativos:
Deben servir para representar y entender el dominio de información de un
problema.
Deben definir las funciones que debe realizar el software.
Deben representar el comportamiento del software
Deben dividirse en los modelos que representan la información, función y
comportamiento para descubrir los detalles por capas
El proceso de análisis debe abarcar desde la información esencial hasta el detalle
de la implementación.
Con estos principios se ha de examinar el dominio de la información para poder entender
completamente una función. Los modelos se emplean para poder comunicar las
características de la función, y su comportamiento.
Además de los principios operativos, existen un conjunto de principios directrices para la
“ingeniería de requisitos”
Entender el problema antes de empezar a crear el modelo de análisis.
Desarrollar prototipos que permitan al usuario entender como será la interacción
hombre-máquina.
Registrar el origen y la razón de cada requisito.
Usar múltiples planteamientos de requisitos, construyendo modelos de datos,
funcionales y de comportamiento, lo que reduce la probabilidad de olvidarse de
algo.
Dar prioridad a los requisitos.
Trabajar para eliminar la ambigüedad.
1.1.1 Dominio de la información

Todas las aplicaciones software pueden denominarse procesamiento de datos, esto es,
el software se construye para procesar datos, aunque también procesa acontecimientos,
aspectos de control del sistema (como un encendido o apagado). Por tanto los datos y
el control residen dentro del dominio de la información de un problema.
El contenido de la información se refiere al conjunto de los objetos individuales de datos
y de control que componen la información que transforma el software (por ejemplo, los
campos individuales componen un registro de información). A su vez los objetos de datos
y control se relacionan con otros objetos, y durante el análisis se han de definir esas
relaciones. El flujo de la información representa como cambian los datos y el control
según se mueven por el sistema.
Y la estructura de la información representa la organización interna de los elementos de
datos y de control.

1.1.2 Modelado
Los modelos de datos son una colección de herramientas conceptuales para describir los
datos, las relaciones de datos, la semántica de los datos y las ligaduras de consistencia.
Sirven para entender mejor la entidad que se va a construir, esto es, entender mejor la
información, la función y el comportamiento del sistema
Se ha de modelar la información que transforma el software, las funciones que permiten
que ocurran las transformaciones, y el comportamiento del sistema cuando ocurren esas
transformaciones.
Durante el análisis de requisitos se crean modelos del sistema a construir, que se
concentran en que debe hacer el sistema, no cómo lo hace. Según el segundo y tercer
principio operativo del análisis, se requieren construir modelos funcionales y modelos de
comportamiento.
Modelos funcionales: se refieren a la transformación de la información, con las
entradas, procesamientos y salidas existentes. Se inicia con un modelo a nivel de
contexto, y con iteraciones se consiguen más detalles funcionales.
Modelos de comportamiento: el software siempre está en un estado, que cambia
cuando ocurre algún acontecimiento. El modelo crea un representación de los
estados del software.
1.1.3 Partición
Dado lo complejo de entender un problema globalmente, se divide en partes más
fácilmente entendibles. Es la partición de la función global. El cuarto principio operativo
del análisis sugiere que se pueden partir los dominios de la información, funcional y de
comportamiento. Se establece una representación jerárquica de la información o de la
función, exponiendo más detalles al movernos verticalmente en la jerarquía, o
descomponiendo el problema en el plano horizontal.
1.1.4 Visiones lógicas y físicas

Una visión lógica o esencial de los requisitos del software presenta las funciones a
conseguir y la información a procesar, sin considerar los detalles de la implementación.
En esta visión el modelo de datos esencial de un elemento de datos, se puede
representar independientemente de la estructura de los datos a implementar.
Una visión física o de implementación introduce la manifestación del mundo real de las
funciones de procesamiento y de estructuras de la información. Sin embargo, esta visión
no debe considerarse como un representación del cómo se ha de hacer, sino de
restricciones que existirán al implementar el sistema.
1.2 Modelado de datos
1.2.1 Análisis de datos
1.2.1.1 Abstracción
Al abordar el análisis de los datos, se ha de tener en cuenta el nivel de abstracción en el
que estemos situados. Existen tres niveles:
Nivel externo o visión de los usuarios particulares, en el que existirán tantos niveles
externos como usuarios distintos.

Nivel conceptual, que contiene no solamente datos sino también las relaciones y
las restricciones siendo un nivel intermedio entre nivel físico y el nivel externo.
Nivel interno o físico, en el que se aborda como se gestionan los datos a nivel
físico, y que depende del sistema gestor de base de datos. Contiene:
o La estrategia de almacenamiento.
o Espacio de almacenamiento.
o Desbordamiento.
o Vías de acceso. (Claves / Índices).
1.2.1.2 Etapas del análisis de datos

1) Análisis: La primera etapa que en la que se analiza la realidad existente, pasando del
modelo externo a un modelo o diseño conceptual.
2) Diseño lógico: A partir del modelo conceptual conseguiremos el modelo lógico, en
función del modelo de base de datos a emplear (en nuestro caso el modelo
relacional).
3) Diseño físico: Finalmente se realizará la implementación del modelo lógico sobre la
base de un diseño físico con las restricciones del sistema elegido.
1.2.2 Modelos de datos
1.2.2.1 Clasificación de los modelos de datos

Los modelos de datos existentes se pueden clasificar en tres grupos:
1. Modelos lógicos basados en objetos: se usan para describir datos en los niveles lógicos.
Proporcionan capacidades estructurales muy flexibles y permiten especificar
explícitamente las ligaduras de datos. Entre los más conocidos están:
Modelo entidad-relación (E-R) o entidad-asociación: consta de una colección de
objetos básicos (entidades) y de relaciones entre estos objetos. Para expresarlos
gráficamente se utiliza un diagrama E-R, que consta de:
Rectángulos: conjuntos de entidades.
Elipses: atributos (campos de cada entidad).
Rombos: relaciones entre conjuntos de entidades.
Líneas: unen los distintos elementos.
Ejemplo:

Modelo orientado a objetos: también basado en una colección de objetos. Un
objeto contiene valores almacenados en variables instancia y fragmentos de
código que operan en el objeto, llamados métodos. Los objetos de los mismos
tipos de valores y los mismos métodos se agrupan en clases, mientras que el paso
de mensaje es la acción para que un objeto pueda acceder a los datos de otro
objeto mediante la invocación de un método de éste. Ejemplo:
2. Modelos lógicos basados en registros: se usan para describir datos en los niveles conceptual
y físico, tanto para especificar la estructura lógica completa de la BD como para
proporcionar una descripción de alto nivel de la implementación. Son los siguientes:
Modelo relacional: se usa una colección de tablas para representar los datos y las
relaciones entre ellos.
Modelo de red: los datos se representan mediante colecciones de registros y las
relaciones mediante enlaces, que hacen de punteros. Los registros se organizan
como colección de grafos dirigidos.
Modelo jerárquico: es similar al modelo de red, salvo en que los registros se
organizan como colecciones de árboles.
3. Modelo de datos físico: se usa para describir datos en el nivel físico, existiendo muy pocos
modelos. Los más conocidos son el modelo unificador y el de memoria de elementos.
1.2.2.2 Objetos de datos, atributos y relaciones

El modelo de datos se compone de tres piezas básicas interrelacionadas, el objeto de
datos, los atributos que describen el objeto de datos, y las relaciones que conectan
objetos de datos entre sí.
El objeto de datos es una representación de la información que ha de contener el
software. Puede ser una entidad externa, un suceso, una estructura (como un fichero), etc.
Los atributos son propiedades de un objeto de datos. Uno o varios de los atributos se
definen como identificador o clave del objeto de datos.
Y las relaciones son las conexiones entre los objetos de datos, las cuales pueden ser
unidireccionales o bidireccionales.

1.2.2.3 Cardinalidad y modalidad
Los elementos básicos del modelado de datos anteriores proporcionan la base del
entendimiento del dominio de información del problema. Sin embargo también hay que
comprender la información adicional relacionada con estos elementos básicos, y que se
define con los conceptos de cardinalidad y de modalidad.
La cardinalidad es la especificación del número de ocurrencias de un objeto que se
relaciona con las ocurrencias de otro, esto es, el número máximo de relaciones de objetos
que pueden participar en una relación.
La cardinalidad no indica si un objeto de datos en particular debe o no participar en la
relación. Esto se indica con la modalidad de una relación, que es cero si no hay necesidad
explícita de que ocurra una relación, o de que sea opcional.
2.- Reglas de modelización. Validación y construcción de modelos

de datos.
2.1 El modelo Entidad/Relación (MER)

En la primera fase del análisis se realiza un estudio del modelo externo existente para
obtener un primer modelo conceptual de datos. El modelo conceptual es más rico
semánticamente que los modelos de datos soportados por los sistemas gestores de bases
de datos, y facilitan la labor del diseñador, ayudándole en su comunicación con el
usuario. Vamos a utilizar el diagrama entidad-relación para realizar dicha fase del análisis,
para identificar lo objetos y sus relaciones.
2.1.1 Definiciones previas

Entidad: Cualquier objeto de datos relativo a la organización acerca del que queremos
guardar información. Una entidad es un objeto que existe y es distinguible de otros objetos.
Tipo o conjunto de entidades: es un conjunto de entidades del mismo tipo que no
necesitan ser disjuntos y que cumplen una definición dada.
Asociación: Es una relación es una entre varias entidades. Generalmente a las entidades
se les asignan sustantivos y a las asociaciones se les asignan verbos.
Grado de una asociación: Número de entidades que participan en una asociación.

Formalmente es una relación matemática entre las entidades
La mayoría de los conjuntos de relaciones en un sistema de bases de datos son binarios
(implica a dos conjuntos de entidades); ocasionalmente, hay conjuntos de relaciones que
implican más de dos conjuntos de entidades, o aquellas que implican una única entidad
(asociaciones reflexivas o unarias). Siempre es posible sustituir un conjunto de relaciones de
grado superior a 2 por varios conjuntos de relaciones binarios distintos.

Tipo de correspondencia: Es el número máximo de ocurrencias de cada entidad
conectada que pueden intervenir en una ocurrencia de la asociación. Se representa
con una etiqueta junto al símbolo de asociación, y son del modo 0:1, 1:1, 1:N o N:M.
Cardinalidades de asignación: Expresan el número de entidades con las que puede
asociarse otra entidad mediante un conjunto de relaciones. Se representan mediante las
etiquetas (0,1), (1,1), (0,N), o (1,N).
Participación o modalidad: Determina la opcionalidad u obligatoriedad de una entidad

en una relación. Si la participación es obligatoria, todas las instancias de la entidad están
asociadas. Por el contrario si existen entidades que pueden no estar relacionadas la
participación se denomina opcional.
Atributo: Unidad básica de información acerca de una entidad con un conjunto de
valores permitidos llamado dominio. Una entidad está representada por un conjunto de
atributos.
Un atributo es una función que asigna un conjunto de entidades a un dominio, de este
modo cada entidad se describe por medio de un conjunto de pares (atributo, valor del
dato), un par para cada atributo del conjunto de entidades.
Superclave: es un conjunto de uno o más atributos que, considerados conjuntamente,
nos permiten identificar de forma única a una entidad en el conjunto de entidades.
Clave candidata: es una superclave para la cual ningún subconjunto es superclave.
Clave primaria: es una clave que elige el diseñador entre las claves candidatas como el
medio principal de identificar entidades.
Entidad débil: Entidades que no tienen atributos suficientes para formar una clave
primaria, depende de los atributos de otra entidad.
Entidad fuerte: es un conjunto de entidades que tiene clave primaria.
Entidad dominante: un miembro de un conjunto de entidades fuerte Entidad

subordinada: un miembro de un conjunto de entidades débil.
Dependencias: Si la existencia de la entidad x depende de la existencia de la entidad y,
entonces se dice que es dependiente por existencia de y. Operativamente, esto significa

que si se suprime y, también se suprime x. La entidad y se dice que es una entidad
dominante y x se dice que es una entidad subordinada.
2.1.2 Pasos a seguir

1) Identificación de entidades, para lo que se precisa conocer el funcionamiento del
área de la organización. Es muy importante elegir el nombre adecuado para la
entidad. Al recopilar requisitos se pide que los clientes listen las cosas que afronta el
proceso de la aplicación o el negocio, que evolucionan a una lista de objetos de
datos de entrada y salida.
2) Identificación de las claves principales. De las entidades se buscarán atributos que
puedan identificar unívocamente todas las ocurrencias de esa entidad. Si hay varias
claves candidatas se elige una de ellas.
3) Identificación de las asociaciones entre entidades. Se trata de relacionar las entidades
obtenidas, si existe conexión entre ellas. De esta relación se ha de encontrar el grado
de la asociación entre las entidades, y la clave principal de la misma.
4) Representación del modelo Entidad-Relación: Las asociaciones y entidades
encontradas se representarán gráficamente, unidas por líneas e indicando el grado de
asociación y las claves principales.
5) Identificación de los atributos de cada entidad: Se listarán los atributos de cada
entidad y asociación que sean significativos para el sistema.
6) Verificaciones: Al final se hará una revisión de los resultados obtenidos y se buscarán la
falta de asociaciones o la existencia de asociaciones redundantes, y se comprobará si
el modelo conceptual obtenido satisface las necesidades de información del sistema.
2.2 Modelo Entidad/Relación extendido
2.2.1 Cardinalidades de un tipo de entidad.

Definimos cardinalidades máximas y mínimas de los tipos de entidad participantes en un
tipo de interrelación, como el número máximo y mínimo de ocurrencias de un tipo de
entidad que pueden estar interrelacionadas con una ocurrencia del otro, u otros tipos de
entidad que participan en el tipo de interrelación. Su representación gráfica es una
etiqueta del tipo (0,1), (1,1), (0,n), o (1,n), según corresponda.
2.2.2 Dependencia en existencia y en identificación

Las interrelaciones se clasifican según el tipo de entidades que vinculan, en fuertes o
regulares si asocian tipos de entidad fuerte o regular, y débiles si asocian un tipo de
entidad débil con un tipo de entidad fuerte. Un tipo de interrelación débil exige siempre
que las cardinalidades del tipo de entidad fuerte sean (1,1).
Dentro de la interrelación débil se pueden distinguir dos tipos de dependencia:
En existencia, cuando en una interrelación está vinculado un tipo de entidad
regular con uno débil, de forma que las ocurrencias de la entidad dependiente
no pueden existir sin la ocurrencia de la entidad de la que dependen. Si
desaparece una ocurrencia de la entidad fuerte, las de la débil en existencia
desaparecen con ella.
En identificación, cuando además de la dependencia en existencia, las
ocurrencias de la entidad débil no se pueden identificar sólo mediante sus

propios atributos, sino que tienen que añadir la clave de la ocurrencia de la que
dependen.
2.2.3 Especialización, generalización y herencia.

Algunas bases de datos pueden ser más adecuadamente expresadas mediante ciertas
extensiones del modelo Entidad-Relación básico. La especialización es el proceso de
designación de subgrupos dentro de un conjunto de entidades, pudiendo haber una o
más características distintivas. La especialización se representa mediante la etiqueta ES.
La generalización es el tipo de interrelación que existe entre un tipo de entidad y los tipos
de entidad más específicos que dependen de él. La generalización responde a la
necesidad de descomposición de tipos de entidad en varios subtipos. En el mundo real
es muy habitual la descomposición de un tipo de entidad, creándose de esta forma una
jerarquía de tipos de entidad, donde se pueden distinguir un supertipo del cual
dependen varios subtipos.La abstracción a este tipo de interrelación entre entidades se
denomina ES_UN_TIPO_DE (IS_A en inglés).
Esta relación tiene la característica de que toda ocurrencia del subtipo es una
ocurrencia del supertipo, pero no al contrario, de modo que las cardinalidades serán
siempre(1,1) en el caso del Supertipo y (0,1) en el casos de los Subtipos.
En el ejemplo, un militar no puede ser a la vez recluta y mando. A este tipo de

generalización se la denomina generalización disjunta.
Si se pueden dar ambos sucesos a la vez. A este nuevo tipo de generalización se le
denomina generalización con solapamiento. En este último tipo de generalización se
suele añadir un campo de tipo que nos permita saber si un miembro de la entidad
superior pertenece a una u otra entidad inferior (o a ambas).

La generalización es una inversión simple de la especialización, y en términos del
diagrama E-R no se distingue entre ellas.
La generalización se usa para hacer resaltar los parecidos entre tipos de entidades de
nivel más bajo y ocultar sus diferencias. Los atributos de los conjuntos de entidades de
nivel más alto se dice que son heredados por los conjuntos de entidades de nivel más
bajo. Aquellos atributos en función de valores que deciden la condición de ‘Ser un‘
subtipo u otro son los atributos discriminantes .
Existen dos métodos para transformar una generalización en tablas:
1) Crear una tabla para el conjunto de entidades de nivel más alto y, para cada
conjunto de entidades de nivel más bajo, crear una tabla que incluya una columna
para cada uno de los atributos de ese conjunto más una columna para cada atributo
de la clave primaria del conjunto de entidades de nivel más alto.
2) No crear una tabla para el conjunto de entidades de nivel más alto. En cambio, crear
una tabla para cada conjunto de entidades de nivel más bajo que incluya, además,
una columna para cada atributo del conjunto de entidades de nivel más alto.
Otro concepto relacionado es el de solapamiento que es cuando una ocurrencia del
supertipo puede pertenecer a más de un subtipo (No Exclusividad).
Si un conjunto de entidades está implicado como un conjunto de entidades de nivel más
bajo en una única relación ES, se está hablando de una jerarquía, mientras que si está
implicado en más de una relación ES, la estructura resultante se llama retículo.
Una de las características más importantes de las jerarquías es la Herencia, por la que todo
atributo del supertipo pasa a ser atributo de los subtipos. Como características cabe
destacar:
Los atributos comunes a todos los subtipos se asignan al supertipo, mientras que
los atributos específicos se asignan al subtipo correspondiente. Lo mismo ocurre
con las interrelaciones.
Las relaciones con todos los subtipos se establecen con el supertipo.
Otro concepto del modelo Entidad-Relación extendido es el de ligaduras de diseño que
sirven para determinar que entidades pueden ser miembros de un conjunto de entidades
de nivel más bajo dado. Pueden ser definidas por condición o por el usuario.
También se diferencian si las entidades pueden pertenecer a más de un conjunto de
entidades de nivel más bajo, pudiendo estos conjuntos de entidades ser disjuntos (una
entidad no puede pertenecer a más de un conjunto de entidades de nivel más bajo) y
solapados (una entidad sí que puede pertenecer diferentes conjuntos de entidades de
nivel más bajo). La entidad solapada es la predeterminada; la ligadura sobre el carácter
disjunto se debe colocar explícitamente en una generalización o especialización.

La ligadura de completitud especifica si un conjunto de nivel más alto debe pertenecer o
no al menos a uno de los conjuntos de entidades de nivel más bajo en una generalización.
Puede ser total (cada entidad de nivel más alto debe pertenecer a un conjunto de
entidades de nivel más bajo) o parcial (algunas entidades de nivel más alto pueden no
pertenecer a algún conjunto de entidades de nivel más bajo).
Por último la agregación es un concepto que se utiliza para poder expresar relaciones
entre relaciones. Es una abstracción a través de la cual las relaciones se tratan como
entidades de nivel más alto.
2.3 Validación de modelos de datos

Los pasos básicos utilizados para la construcción de modelos son los mismos para todos los
métodos de modelización:
1) Selección del modelo
2) Ajuste del modelo y
3) Validación del modelo
Estos 3 pasos básicos se usan de forma iterativa hasta que se ha desarrollado un modelo
apropiado para los datos. Si en el paso de validación del modelo se identifican problemas
con el modelo actual se repite todo el proceso de modelización utilizando la información
obtenida durante la validación para seleccionar o ajustar un modelo mejorado.
La medición del software está adquiriendo una gran importancia debido a que cada vez
se hace más patente la necesidad de obtener datos objetivos que permitan evaluar,
predecir y mejorar la calidad del software así como el tiempo y coste de desarrollo del
mismo.
El valor de las mediciones aumenta cuando se realiza sobre modelos construidos en las
primeras fases del proyecto ya que los resultados obtenidos permiten tenerlo bajo control
en todo momento y corregir a tiempo posibles desviaciones. La proliferación actual de
métricas y el gran volumen de datos que se maneja ha puesto de manifiesto que las
técnicas clásicas de análisis de datos son insuficientes para lograr los objetivos perseguidos.
En este trabajo se presenta la forma en que pueden aplicarse las nuevas técnicas de
minería de datos en la construcción y validación de modelos de ingeniería del software,
cambiando el análisis tradicional de datos dirigido a la verificación por un enfoque de
análisis de datos dirigido al descubrimiento del conocimiento.
Los estudios relacionados con la medición en el nivel de la especificación de requisitos se
han centrado fundamentalmente en el desarrollo de métricas para determinar el tamaño
y la funcionalidad del software. Entre las de mayor difusión se encuentran las métricas de
puntos de función, métricas Bang o los puntos objeto. La medición de atributos de calidad
de las especificaciones de requisitos del software ha sido también objeto de algunos
trabajos que van desde la medición de especificaciones formales hasta la aplicación de
métricas para evaluar la calidad de especificaciones expresadas informalmente en
lenguaje natural (métricas de facilidad de comprensión del texto contenido en los
documentos o métricas de estructura y organización en documentos convencionales y
con hipertexto), pasando por técnicas encaminadas a determinar el cumplimiento de los
estándares, directrices, especificaciones y procedimientos, que requieren información
procedente de revisiones técnicas, inspecciones o auditorias. La creciente adopción de la
tecnología de orientación a objetos en el desarrollo de software ha dado lugar a la
aparición de nuevas métricas específicas para este tipo de sistemas. Recientemente se
han propuesto métricas para la evaluación de la calidad a partir de modelos producidos
en etapas iniciales del ciclo de vida, como son las métricas de calidad y complejidad en

modelos OMT, métricas de calidad de los diagramas de clases en UML o las técnicas de
medición de modelos conceptuales basados en eventos.
La proliferación actual de métricas y la necesidad de medir diferentes aspectos del
software está contribuyendo a crear confusión sobre las relaciones entre tales medidas, así
como sobre su forma y ámbito de aplicación. Este hecho ha abierto una nueva vía en la
investigación orientada hacia la propuesta de modelos, arquitecturas y marcos de
referencia (“frameworks”) que permitan la organización de las medidas y la clasificación
de las entidades de software susceptibles de medir. La construcción de modelos sobre
diferentes aspectos del software requiere la recolección de numerosos datos procedentes
de observaciones empíricas. Los avances tecnológicos actuales posibilitan la rápida
obtención de grandes cantidades de datos de fuentes muy diversas, así como el
almacenamiento eficiente de los mismos. Dichos datos encierran información muy valiosa
que puede tratarse mediante los métodos tradicionales de análisis de datos, sin embargo
estos métodos no son capaces de encontrar toda la información útil latente en la gran
masa de datos que se maneja. En ese contexto, las técnicas de minería de datos surgen
como las mejores herramientas para realizar exploraciones más profundas y extraer
información nueva, útil y no trivial que se encuentra oculta en grandes volúmenes de
datos.
La minería de datos ha dado lugar a una paulatina sustitución del análisis de datos dirigida
a la verificación por un enfoque de análisis de datos dirigido al descubrimiento del
conocimiento. La principal diferencia entre ambos se encuentra en que en el último se
descubre información sin necesidad de formular previamente una hipótesis. La aplicación
automatizada de algoritmos de minería de datos permite detectar fácilmente patrones en
los datos, razón por la cual esta técnica es mucho más eficiente que el análisis dirigido a la
verificación cuando se intenta explorar datos procedentes de repositorios de gran tamaño
y complejidad elevada. Dichas técnicas emergentes se encuentran en continua evolución
como resultado de la colaboración entre campos de investigación tales como bases de
datos, reconocimiento de patrones, inteligencia artificial, sistemas expertos, estadística,
visualización, recuperación de información, y computación de altas prestaciones.
Los algoritmos de minería de datos se clasifican en dos grandes categorías: supervisados o
predictivos y no supervisados o de descubrimiento del conocimiento.
1) Los algoritmos supervisados o predictivos predicen el valor de un atributo (etiqueta),
de un conjunto de datos, conocidos otros atributos (atributos descriptivos). A partir de
datos cuya etiqueta se conoce se induce una relación entre dicha etiqueta y otra
serie de atributos. Esas relaciones sirven para realizar la predicción en datos cuya
etiqueta es desconocida. Esta forma de trabajar se conoce como aprendizaje
supervisado y se desarrolla en dos fases:
Entrenamiento (construcción de un modelo usando un subconjunto de datos con
etiqueta conocida) y
prueba (prueba del modelo sobre el resto de los datos).
2) Cuando una aplicación no es lo suficientemente madura no tiene el potencial
necesario para una solución predictiva, en ese caso hay que recurrir a los métodos no
supervisados o de descubrimiento del conocimiento que descubren patrones y
tendencias en los datos actuales (no utilizan datos históricos). El descubrimiento de esa
información sirve para llevar a cabo acciones y obtener un beneficio (científico o de
negocio) de ellas.
En la tabla siguiente se muestran algunas de las técnicas de minería de ambas categorías:

Supervisados No supervisados
Árboles de decisión Detección de desviaciones
Inducción neuronal Segmentación
Regresión Agrupamiento (“clustering”)
Series temporales Reglas de asociación
Patrones secuenciales
La aplicación de los algoritmos de minería de datos requiere la realización de una serie de

actividades previas encaminadas a preparar los datos de entrada debido a que, en
muchas ocasiones dichos datos proceden de fuentes heterogéneas, no tienen el formato
adecuado o contienen ruido. Por otra parte, es necesario interpretar y evaluar los
resultados obtenidos. El proceso completo consta de las siguientes etapas [Cabena et al.,
1998]:
1) Determinación de objetivos
2) Preparación de datos
Selección: Identificación de las fuentes de información externas e internas y
selección del subconjunto de datos necesario.
Preprocesamiento: estudio de la calidad de los datos y determinación de las
operaciones de minería que se pueden realizar.
3) Transformación de datos: conversión de datos en un modelo analítico.
4) Minería de datos: tratamiento automatizado de los datos seleccionados con una
combinación apropiada de algoritmos.
5) Análisis de resultados: interpretación de los resultados obtenidos en la etapa anterior,
generalmente con la ayuda de una técnica de visualización.
6) Asimilación de conocimiento: aplicación del conocimiento descubierto.
Aunque los pasos anteriores se realizan en el orden en que aparecen, el proceso es
altamente iterativo, estableciéndose retroalimentación entre los mismos. Además, no todos
los pasos requieren el mismo esfuerzo, generalmente la etapa de preprocesamiento es la
más costosa ya que representa aproximadamente el 60 % del esfuerzo total, mientras que
la etapa de minería sólo representa el 10%.
Las técnicas de minería de datos se están utilizando desde hace varios años para la
obtención de patrones en los datos y para la extracción de información valiosa en el
campo de la Ingeniería del Software. Entre estas aplicaciones podemos citar la utilización
de árboles de decisión en la construcción de modelos de clasificación de diferentes
características del desarrollo de software, la aplicación de técnicas de “clustering” en la
planificación del mantenimiento y en la estimación de la fiabilidad del software o el uso de
redes neuronales en la predicción de riesgos de mantenimiento en módulos de programa.
La mayor parte de los trabajos realizados están dirigidos a la obtención de modelos de
estimación de esfuerzo de desarrollo y modelos de predicción de diferentes aspectos de la
calidad del software. En ambos casos, las métricas tanto de productos como de procesos
juegan un papel importante, constituyendo la base para la construcción de los modelos y
posterior validación de los mismos. En publicaciones recientes aparece la introducción de
algoritmos de minería en la realización de validaciones de modelos obtenidos mediante
otras técnicas. En estos trabajos se comprueba la validez de modelos de estimación
mediante métodos de regresión, redes neuronales, algoritmos genéticos, etc., se validan
métricas, e incluso “frameworks” de medición.

2.4 Apéndice: Modelo Entidad/Relación extendido según Métrica v.3
MÉTRICA versión 3 puede ser utilizada libremente con la única restricción de citar la fuente
de su propiedad intelectual, es decir, el Ministerio de Administraciones Públicas. Este
apéndice es un extracto de la guía de técnicas de Métrica v.3.

Técnicas y Prácticas 61
Modelo Entidad/Relación Extendido

Se trata de una técnica cuyo objetivo es la representación y definición de todos los datos
que se introducen, almacenan, transforman y producen dentro de un sistema de información, sin
tener en cuenta las necesidades de la tecnología existente, ni otras restricciones.
Dado que el modelo de datos es un medio para comunicar el significado de los datos, las
relaciones entre ellos y las reglas de negocio de un sistema de información, una organización
puede obtener numerosos beneficios de la aplicación de esta técnica, pues la definición de los
datos y la manera en que éstos operan son compartidos por todos los usuarios.
Las ventajas de realizar un modelo de datos son, entre otras:

− Comprensión de los datos de una organización y del funcionamiento de la organización.
− Obtención de estructuras de datos independientes del entorno físico.
− Control de los posibles errores desde el principio, o al menos, darse cuenta de las
deficiencias lo antes posible.
− Mejora del mantenimiento.
Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es mucho más
estable que la estructura de procesos. Como resultado, una estructura de datos estable e
integrada proporciona datos consistentes que puedan ser fácilmente accesibles según las
necesidades de los usuarios, de manera que, aunque se produzcan cambios organizativos, los
datos permanecerán estables.
Este diagrama se centra en los datos, independientemente del procesamiento que los
transforma y sin entrar en consideraciones de eficiencia. Por ello, es independiente del entorno
físico y debe ser una fiel representación del sistema de información objeto del estudio,
proporcionando a los usuarios toda la información que necesiten y en la forma en que la
necesiten.
Descripción
El modelo entidad/relación extendido describe con un alto nivel de abstracción la distribución
de datos almacenados en un sistema. Existen dos elementos principales: las entidades y las
relaciones. Las extensiones al modelo básico añaden además los atributos de las entidades y la
jerarquía entre éstas. Estas extensiones tienen como finalidad aportar al modelo una mayor
capacidad expresiva.
Los elementos fundamentales del modelo son los siguientes:
Entidad
Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la
base de datos. La estructura genérica de un conjunto de entidades con las mismas características
se denomina tipo de entidad.
Existen dos clases de entidades: regulares, que tienen existencia por sí mismas, y débiles
cuya existencia depende de otra entidad. Las entidades deben cumplir las siguientes tres reglas:
− Tienen que tener existencia propia.
Metodología MÉTRICA Versión 3 © Ministerio de Administraciones Públicas

62 Técnicas y Prácticas
− Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás.

− Todas las ocurrencias de un tipo de entidad deben tener los mismos atributos.
Relación
Es una asociación o correspondencia existente entre una o varias entidades. La relación
puede ser regular, si asocia tipos de entidad regulares, o débil, si asocia un tipo de entidad débil
con un tipo de entidad regular. Dentro de las relaciones débiles se distinguen la dependencia en
existencia y la dependencia en identificación.
Se dice que la dependencia es en existencia cuando las ocurrencias de un tipo de entidad

débil no pueden existir sin la ocurrencia de la entidad regular de la que dependen. Se dice que la
dependencia es en identificación cuando, además de lo anterior, las ocurrencias del tipo de
entidad débil no se pueden identificar sólo mediante sus propios atributos, sino que se les tiene
que añadir el identificador de la ocurrencia de la entidad regular de la cual dependen.
Además, se dice que una relación es exclusiva cuando la existencia de una relación entre
dos tipos de entidades implica la no existencia de las otras relaciones.
Una relación se caracteriza por:

− Nombre: que lo distingue unívocamente del resto de relaciones del modelo.
− Tipo de correspondencia: es el número máximo de ocurrencias de cada tipo de entidad
que pueden intervenir en una ocurrencia de la relación que se está tratando.
Conceptualmente se pueden identificar tres clases de relaciones:
− Relaciones 1:1: Cada ocurrencia de una entidad se relaciona con una y sólo una
ocurrencia de la otra entidad.
− Relaciones 1:N: Cada ocurrencia de una entidad puede estar relacionada con cero,
una o varias ocurrencias de la otra entidad.
− Relaciones M:N: Cada ocurrencia de una entidad puede estar relacionada con cero,
una o varias ocurrencias de la otra entidad y cada ocurrencia de la otra entidad puede
corresponder a cero, una o varias ocurrencias de la primera.
− Cardinalidad: representa la participación en la relación de cada una de las entidades
afectadas, es decir, el número máximo y mínimo de ocurrencias de un tipo de entidad que
pueden estar interrelacionadas con una ocurrencia de otro tipo de entidad. La cardinalidad
máxima coincide con el tipo de correspondencia.
Según la cardinalidad, una relación es obligatoria, cuando para toda ocurrencia de un tipo de
entidad existe al menos una ocurrencia del tipo de entidad asociado, y es opcional cuando, para
toda ocurrencia de un tipo de entidad, puede existir o no una o varias ocurrencias del tipo de
entidad asociado.
Dominio
Es un conjunto nominado de valores homogéneos. El dominio tiene existencia propia con
independencia de cualquier entidad, relación o atributo.
Atributo
Es una propiedad o característica de un tipo de entidad. Se trata de la unidad básica de
información que sirve para identificar o describir la entidad. Un atributo se define sobre un
dominio. Cada tipo de entidad ha de tener un conjunto mínimo de atributos que identifiquen
unívocamente cada ocurrencia del tipo de entidad. Este atributo o atributos se denomina
© Ministerio de Administraciones Públicas Metodología MÉTRICA Versión 3
identificador principal. Se pueden definir restricciones sobre los atributos, según las cuales un
atributo puede ser:
− Univaluado, atributo que sólo puede tomar un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.
− Obligatorio, atributo que tiene que tomar al menos un valor para todas y cada una de las
ocurrencias del tipo de entidad al que pertenece.
Además de estos elementos, existen extensiones del modelo entidad/relación que
incorporan determinados conceptos o mecanismos de abstracción para facilitar la representación
de ciertas estructuras del mundo real:
− La generalización, permite abstraer un tipo de entidad de nivel superior (supertipo) a partir
de varios tipos de entidad (subtipos); en estos casos los atributos comunes y relaciones de
los subtipos se asignan al supertipo. Se pueden generalizar por ejemplo los tipos profesor y
estudiante obteniendo el supertipo persona.
− La especialización es la operación inversa a la generalización, en ella un supertipo se
descompone en uno o varios subtipos, los cuales heredan todos los atributos y relaciones
del supertipo, además de tener los suyos propios. Un ejemplo es el caso del tipo empleado,
del que se pueden obtener los subtipos secretaria, técnico e ingeniero.
− Categorías. Se denomina categoría al subtipo que aparece como resultado de la unión de
varios tipos de entidad. En este caso, hay varios supertipos y un sólo subtipo. Si por ejemplo
se tienen los tipos persona y compañía y es necesario establecer una relación con vehículo,
se puede crear propietario como un subtipo unión de los dos primeros.
− La agregación, consiste en construir un nuevo tipo de entidad como composición de otros y
su tipo de relación y así poder manejarlo en un nivel de abstracción mayor. Por ejemplo, se
tienen los tipos de entidad empresa y solicitante de empleo relacionados mediante el tipo de
relación entrevista; pero es necesario que cada entrevista se corresponda con una
determinada oferta de empleo. Como no se permite la relación entre tipos de relación, se
puede crear un tipo de entidad compuesto por empresa, entrevista y solicitante de empleo y
relacionarla con el tipo de entidad oferta de empleo. El proceso inverso se denomina
desagregación.
− La asociación, consiste en relacionar dos tipos de entidades que normalmente son de
dominios independientes, pero coyunturalmente se asocian.
La existencia de supertipos y subtipos, en uno o varios niveles, da lugar a una jerarquía,
que permitirá representar una restricción del mundo real.
Una vez construido el modelo entidad/relación, hay que analizar si se presentan

redundancias. Para poder asegurar su existencia se deben estudiar con mucho detenimiento las
cardinalidades mínimas de las entidades, así como la semántica de las relaciones.
Los atributos redundantes, los que se derivan de otros elementos mediante algún calculo,
deben ser eliminados del modelo entidad/relación o marcarse como redundantes.
Igualmente, las relaciones redundantes deben eliminarse del modelo, comprobando que al
eliminarlas sigue siendo posible el paso, tanto en un sentido como en el inverso, entre las dos
entidades que unían.

Notación
Entidad
La representación gráfica de un tipo de entidad regular es un rectángulo etiquetado con el
nombre del tipo de entidad. Un tipo de entidad débil se representa con dos rectángulos
concéntricos con su nombre en el interior.
ENTIDAD ENTIDAD
REGULAR DÉBIL
Relación
Se representa por un rombo unido a las entidades relacionadas por dos líneas rectas a los
lados. El tipo de correspondencia se representa gráficamente con una etiqueta 1:1, 1:N o M:N,
cerca de alguno de los vértices del rombo, o bien situando cada número o letra cerca de la entidad
correspondiente, para mayor claridad.
1 N
ENTIDAD 1 Relación ENTIDAD 2
La representación gráfica de las cardinalidades se realiza mediante una etiqueta del tipo
(0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que corresponda. Si se
representan las cardinalidades, la representación del tipo de correspondencia es redundante.
(0,1) (1,n)
ENTIDAD 1 Relación ENTIDAD 2

Atributo
Un atributo se representa mediante una elipse, con su nombre dentro, conectada por una
línea al tipo de entidad o relación.
En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un círculo más
pequeño con el nombre del atributo a un lado. También pueden representarse en una lista
asociada a la entidad. El identificador aparece con el nombre marcado o subrayado, o bien con su
círculo en negro.
atributo1 atributo2
atributo1
ENTIDAD ENTIDAD atributo2

atributo3
atributo3
Exclusividad
En la representación de las relaciones exclusivas se incluye un arco sobre las líneas que
conectan el tipo de entidad a los dos o más tipos de relación.
1:N
ENTIDAD 1 Relación 1 ENTIDAD 2
Relación 2 ENTIDAD 3
1:N

Jerarquía (tipos y subtipos)

La representación de las jerarquías se realiza mediante un triángulo invertido, con la base
paralela al rectángulo que representa el supertipo y conectando a éste y a los subtipos. Si la
división en subtipos viene determinada en función de los valores de un atributo discriminante, éste
se representará asociado al triángulo que representa la relación.
SUPERTIPO
Atributo
Es_un discriminante
SUBTIPO 1 SUBTIPO 2
En el triángulo se representará: con una letra d el hecho de que los subtipos sean disjuntos,
con un círculo o una O si los subtipos pueden solaparse y con una U el caso de uniones por
categorías. La presencia de una jerarquía total se representa con una doble línea entre el
supertipo y el triángulo.
EMPLEADO EMPLEADO
No disjuntos O d
Disjuntos
Ingeniero Gerente Técnico Contable
EMPLEADO persona empresa
Jerarquía
total
Categoría U
Es_un (unión)
asalariado subcontratado CUENTA

Ejemplo.
Modelo entidad-relación extendido para un sistema de gestión de técnicos y su asignación a
proyectos dentro de una empresa u organización.
Como se aprecia en el diagrama, TÉCNICO es un subtipo de EMPLEADO, generado por

especialización, pues era necesario para establecer la relación Trabaja en con PROYECTO, ya
que no todos los empleados de la empresa, como los administrativos, son susceptibles de trabajar
en un proyecto. La entidad TÉCNICO tendrá los atributos de EMPLEADO más el atributo nivel.
nombre
núm. nombre
dirección cod-depto
matrícula depto.
N 1
EMPLEADO Pertenece DEPARTAMENTO
fecha
asignación
Es_un
nivel fecha cese
M
TÉCNICO Trabaja en
ADMINISTRATIVO
N
cod-proyecto PROYECTO
cliente
nombre
proyecto fecha fin
fecha inicio
Los tipos de correspondencia son 1:N entre DEPARTAMENTO y EMPLEADO, pues un

departamento tiene 1 o varios empleados. Entre TÉCNICO y PROYECTO es M:N, pues un técnico
puede trabajar en 1 o varios proyectos, y en un proyecto trabajan 1 o varios técnicos.
Por otro lado, se han incluido atributos que caracterizan la relación Trabaja en, como son
fecha de asignación y fecha de cese, ya que un técnico no siempre estará trabajando en un
proyecto, sino en determinado periodo. (Nota.- Esta notación es la más habitual, pero MÉTRICA
Versión 3 no exige su utilización).

Tema II.II.2. Técnicas de evaluación de alternativas y análisis
de viabilidad. Personal, procedimientos, datos,
software y hardware. Criterios.
Índice
1.- TÉCNICAS DE EVALUACIÓN DE ALTERNATIVAS Y ANÁLISIS DE VIABILIDAD. 2
2.- ALTERNATIVAS EN GESTIÓN DE RECURSOS HUMANOS. 3
2.1 Reclutamiento 3
2.1.1 Reclutamiento interno 3
2.1.2 Reclutamiento Externo 5
2.2 Outsourcing 6
3.- ALTERNATIVAS RESPECTO A LOS DATOS 8
3.1 Base de datos centralizada 8
3.2 Base de datos distribuida 8
3.3 Bases de datos federadas 9
4.- ALTERNATIVAS EN SOFTWARE 11
4.1 Producción de software a medida 11
4.1.1 Producción propia del software 11
4.1.2 Contratación externa de software a medida 11
4.2 Compra de paquetes y programas de software 11
4.2.1 Evaluación del software comercial 11
4.2.2 Licencias para productos de software 12
5.- ALTERNATIVAS EN HARDWARE. 13
5.1 Compra de equipos nuevos 13
5.2 Alquiler de equipos 13
5.2.1 Localización de los equipos 13
5.2.2 Posibilidades financieras: leasing. 15
5.3 Compra de equipos usados 15
6.- CRITERIOS. EVALUACIÓN DE ALTERNATIVAS. 16
7.- ANÁLISIS DE VIABILIDAD 16
7.1 Viabilidad operacional 17
7.2 Viabilidad Técnica 17
7.3 Viabilidad financiera y económica 18

1.- Técnicas de evaluación de alternativas y análisis de viabilidad.
La evaluación de alternativas es una de las fases del proceso de toma de decisiones. Las
decisiones en el seno de una organización son, por lo general, de naturaleza compleja,
principalmente porque se ven afectadas varias dimensiones: técnica, económica,
humana, social...
Puede afirmarse que la valoración de los distintos aspectos de una decisión concreta no se
puede realizar, en la inmensa mayoría de los casos, de manera únicamente cuantitativa;
los aspectos cualitativos son numerosos e inevitables, y su relevancia, por lo menos, tan
grande como la de los cuantitativos. A pesar de ello, la valoración cuantitativa de las
distintas alternativas que se presentan es, sin lugar a dudas, el instrumento más objetivo de
que dispone el directivo ante la toma de decisiones. No quiere decir esto que haya que
eliminar los aspectos cualitativos del ámbito de la decisión, ni mucho menos; pero sí que se
puede afirmar que la valoración cuantitativa es una información de base muy útil.
El proceso formal para la toma de decisiones consta de cinco etapas.
a) Definición del Problema
Esta primera fase es más difícil e importante de lo que a priori pudiera parecer. No hay
que confundir la identificación del problema con la definición del mismo, de la misma
manera que no hay que confundir el hecho de que un enfermo detecte los síntomas
de su enfermedad con la correcta diagnosis de la misma. La definición del problema
en muchos casos puede condicionar la decisión final. Tras esta fase, el problema debe
ser transmitible a otras personas de forma inequívoca.
b) Establecimiento de Criterios
En esta fase se deben explicitar las distintas dimensiones o aspectos que afectan al
problema. Los criterios son el instrumento de selección entre las distintas alternativas
que se presentan, pues van a ser valoradas en relación al grado de satisfacción de
cada uno de ellos.
A continuación, a título de ejemplo y sin pretender ser exhaustivos, se relacionan
algunos posibles criterios:
– Impacto sobre los beneficios a corto plazo.
– Actitud de los empleados.
– Impacto sobre el mercado.
– Posibilidades financieras.
– Influencia sobre el prestigio y la imagen de la firma.
– Usos y costumbre del mercado.
c) Generar las Alternativas de Decisión
Esta fase exige un esfuerzo creativo importante, consistente en elaborar los distintos
cursos de acción que es posible emprender para resolver el problema. A menudo, las
alternativas mas obvias no son necesariamente las mejores.
Puede ocurrir que durante el análisis surjan nuevas alternativas que no se habían
considerado en un principio; lo cual puede requerir una redefinición del problema y
volver a comenzar todo el proceso.
d) Valoración de las alternativas con respecto a los criterios

Consiste en evaluar las consecuencias previsibles de cada una de las alternativas en
relación con una serie de dimensiones (criterios). Es decir, hacerse la siguiente
pregunta: ''¿Qué nivel de satisfacción de los requisitos que imponen los distintos criterios
alcanza cada alternativa?". Dos consideraciones acerca de esta etapa:
Existen numerosos criterios importantes que son de difícil valoración cuantitativa. Esto
no quiere decir que no se puedan evaluar, simplemente que el resultado no será un
número, sino una apreciación de tipo menos preciso (por ejemplo: mal, regular, bien,
muy bien).
La información en base a la cual se realiza la valoración es, por la misma naturaleza de
la decisión, estimaciones de valores futuros, y que por lo tanto, están sujetas a
variabilidad y por tanto riesgo.
e) Toma de la Decisión
Por último, el decisor tendrá ante sí una relación de los distintos criterios de satisfacción
de éstos por cada una de las alternativas. Consiste esta etapa en ponderar la
importancia relativa de cada uno de los criterios para elegir la alternativa que
suministra un mejor cumplimiento conjunto de todos ellos.
El párrafo anterior no se pretende ocultar que esta fase no está exenta de cierto grado
de intuición, mayor cuanto más grande sea la relevancia de los criterios cualitativos
sobre los cuantitativos. Lo que sí se puede afirmar, es que el hecho de realizar este
análisis supone un paso importante en la formalización del proceso de decisión, que
permite reducir el grado de subjetividad y argumentar las decisiones tomadas de
forma más contundente.
2.- Alternativas en gestión de recursos humanos.

En la gestión de recursos humanos pueden distinguirse dos alternativas mayoritarias: la
utilización de personal propio (reclutamiento) y el outsourcing. En el primer caso, la tarea
puede implicar la contratación de personal externo o la asignación de personal interno al
proyecto. En el segundo caso, se trata de un contrato de consultoría y asistencia con una
empresa de servicios.
2.1 Reclutamiento
El reclutamiento es el proceso de identificar e interesar a candidatos capacitados para
llenar una vacante. El proceso de reclutamiento se inicia con la búsqueda y termina
cuando se reciben las solicitudes de empleo.
Las descripciones de puesto constituyen un instrumento esencial para los reclutadores, ya

que proporcionan la información básica sobre las funciones y responsabilidades que
incluye cada vacante.
2.1.1 Reclutamiento interno
El reclutamiento interno tiene lugar cuando, al presentarse determinada vacante, la

empresa intenta llenarla mediante la reubicación de los empleados, los cuales pueden ser
ascendidos (movimiento vertical) o transferidos (movimiento horizontal) o transferidos con
promoción (movimiento diagonal).

2.1.1.1 Ventajas
Entre las ventajas que ofrece el reclutamiento interno, se pueden destacar las siguientes:
x Presenta mayor índice de validez y de seguridad, puesto que ya se conoce al

candidato, se le evaluó durante cierto período y fue sometido al concepto de sus
jefes; en la mayor parte de las veces, no necesita período experimental,
integración, ni inducción en la organización o de informaciones amplias al
respecto;
x Es una poderosa fuente de motivación para los empleados, pues éstos vislumbran
la posibilidad de progreso dentro de la organización, gracias a las oportunidades
ofrecidas a quienes presentan condiciones para un futuro ascenso;
x Aprovecha las inversiones de la empresa en entrenamiento de personal, que

muchas sólo tiene su retorno cuando el empleado pasa a ocupar cargos más
elevados y complejos;
x Desarrolla un sano espíritu de competencia entre el personal, teniendo presente

que las oportunidades se ofrecerán a quienes realmente demuestren condiciones
para merecerlas.
2.1.1.2 Desventajas
Entre las desventajas del reclutamiento interno se pueden enumerar las siguientes:
x Exige que los empleados nuevos tengan condiciones de potencial de desarrollo

para poder ascender, al menos, a algunos niveles por encima del cargo donde
están ingresando, y motivación suficiente para llegar allí; si la organización
realmente no ofrece oportunidades de progreso en el momento adecuado, se
corre el riesgo de frustrar a los empleados en su potencial y en sus ambiciones,
causando diversas consecuencias, como apatía, desinterés, o el retiro de la
organización con el propósito de aprovechar oportunidades fuera de ella;
x Puede generar un conflicto de intereses, ya que al explicar las oportunidades de

crecimiento dentro de la organización, tiende a crecer una actitud negativa en los
empleados que por no demostrar condiciones, no realizan esas oportunidades;
cuando se trata de jefes que por largo tiempo que no tienen ningún ascenso en la
organización o que no tiene potencial de desarrollo para ascender más allá de
suposición actual, éstos pueden pasar a tratar de ocupar los cargos subalternos
con personal de potencial limitado, con el propósito de aprovechar nuevas
oportunidades en el futuro o entonces pasar a "sofocar" el desempeño y las
aspiraciones de los subordinados cuando notan que, en el futuro, podrían
sobrepasarlos;
x Cuando se administra de manera incorrecta, puede conducir a la situación que

Lawrence Peter denomina "principio de Peter", las empresas, al promover
incesantemente a sus empleados, los elevan siempre a la posición donde
demuestra, en principio, competencia en algún cargo, la organización, para
premiar su desempeño y aprovechar su capacidad, lo asciende sucesivamente
hasta el cargo en que el empleado, por mostrarse incompetente se estanca, una
vez que la organización quizá no tenga cómo devolverlo a la posición anterior;
x Cuando se efectúa continuamente, puede llevar a los empleados a una progresiva

limitación de las políticas y directrices de la organización, ya que éstos, al convivir
sólo con los problemas y con las situaciones de su organización, se adaptan a ellos
y pierden la creatividad y la actitud de innovación; aunque la organización puede

desarrollar esfuerzos destinados a presentar soluciones importadas de otras
empresas;
2.1.2 Reclutamiento Externo
El reclutamiento ocurre cuando al existir determinada vacante, una organización intenta

cubrirla con personas ajenas, es decir, con candidatos externos atraídos por las técnicas
de reclutamiento.
2.1.2.1 Ventajas
Las ventajas destacables del reclutamiento externo son:
x Renueva y enriquece los recursos humanos de la organización sobre todo cuando

la política consiste en recibir personal que tenga idoneidad igual o mayor que la
existente en la empresa;
x Aprovecha las inversiones en preparación y en desarrollo de personal efectuadas

por otras empresas o por los propios candidatos. Esto no significa que la empresa
deje de hacer esas inversiones de ahí en adelante, sino que usufructúa de
inmediato el retorno de la inversión ya efectuada pro lo demás, hasta tal punto
que muchas empresas prefieren reclutar externamente y pagar salarios más
elevados, precisamente para evitar gastos adicionales de entrenamiento y
desarrollo y obtener resultados de desempeño a corto plazo.
2.1.2.2 Desventajas
Algunas de las más importantes desventajas del reclutamiento externo se describen a
continuación:
x Generalmente tarda más que el reclutamiento interno. El período empleado en la

elección e implementación de las técnicas más adecuadas, con influencia de las
fuentes de reclutamiento, con atracción y presentación de los candidatos, con
recepción y preparación inicial, con destino a la selección, a los exámenes u otros
compromisos y con el ingreso, no es pequeño; y cuando más elevado el nivel del
cargo, resulta mayor ese período;
x Es más costeso y exige inversiones y gastos inmediatos con anuncios de prensa,

honorarios de agencias de reclutamiento, gastos operacionales relativos a salarios
y obligaciones sociales del equipo de reclutamiento, material de oficina,
formularios, etc.
x En principio, es menos seguro que el reclutamiento interno, ya que los candidatos

externos son desconocidos y provienen de orígenes y trayectorias profesionales que
la organización no está en condiciones de verificar con exactitud. A pesar de las
técnicas de selección y de los pronósticos presentados, las empresas por lo general
dan ingreso al personal mediante un contrato que estipula un período de prueba,
precisamente para tener garantía frente a la relativa inseguridad del proceso.
x Cuando monopoliza las vacantes y las oportunidades dentro de la empresa,

puede frustrar al personal, ya que éste pasa a percibir barreras imprevistas que se
oponen a su desarrollo profesional. Los empleados pueden percibir el monopolio
del reclutamiento externo como una política de deslealtad de la empresa hacia su
personal.

x Por lo general, afecta la política salarial de la empresa al actuar sobre su régimen
de salarios, principalmente cuando la oferta y la demanda de recursos humanos
están en situación de desequilibrio.
2.2 Outsourcing
El "outsourcing", también llamado "tercerización" es la contratación de un tercero para
ejecutar actividades previamente (o posiblemente) realizadas dentro de la orgnización. En
el campo de las tecnologías de la información y las comunicaciones (TIC), algunas de las
áreas que se han tercerizado con mayor frecuencia son la operación de infraestructura
tecnológica, las aplicaciones de sistemas y los procesos de negocio de la empresa.
El outsourcing requiere una contratación formal por un período de tiempo fijo y puede
involucrar la transferencia de activos y/o recursos humanos de la organización al
proveedor de servicios de outsourcing.
El proveedor de outsourcing de TIC asume la responsabilidad de gestionar el servicio de
tecnologías de la información de una empresa. Esto incluye:
1. Outsourcing de sistemas: administración y operación de servidores, soporte técnico,
PCs, redes y otros activos tecnológicos. Puede incluir también operaciones de
ayuda a usuarios (help desk) y de mantenimiento de equipos.
2. Outsourcing de aplicaciones: donde el proveedor asume contractualmente la
responsabilidad de administrar y mejorar los sistemas (paquetes de software o
desarrollos internos) de una empresa.
El outsourcing de procesos de negocio es la tercerización de procesos o áreas funcionales
de una empresa, como por ejemplo:
o Administración: facturación, servicios a accionistas, servicios generales, compras,
etc.
o Servicio al cliente: call centers, telemarketing, etc.
o Finanzas: tesorería, cobranzas, pagos, contabilidad, administración de activos,
etc.
o Recursos humanos: administración de beneficios, procesamiento de nómina,
compensación, entrenamiento, etc.
o Manufactura: administración de materiales, fabricación, empaquetado,
ensamblaje, etc.
o Logística: inventario y almacenaje, transporte y distribución, etc.
Para determinar si el outsourcing es una alternativa válida para la organización, deben
tenerse en cuenta tres aspectos:
1. La organización puede elegir enfocar sus recursos financieros y humanos en
desarrollar el negocio medular (el que lo diferencia de sus competidores) y dejar la
ejecución de actividades operativas, aún siendo importantes, en manos de terceros.
2. Es posible que tenga un sentido estratégico, financiero y de negocio realizar
internamente todas las actividades y procesos.
3. Puede resultar beneficioso realizar actividades no medulares a un menor coste y más
eficientemente que lo permitido por las capacidades internas actuales.
La finalidad de un contrato de outsourcing para la empresa contratante es la consecución
de todos o algunos de los siguientes objetivos:
o Reducir costes al aumentar la productividad y eficiencia de las operaciones,
funciones y procesos.

o Obtener competencias, habilidades y recursos.
o Enfocar los recursos de gestión en el negocio medular, en las competencias
diferenciadoras del negocio, en desarrollar y mejorar las relaciones con sus
clientes.
o Obtener o mejorar capacidades tecnológicas.
o Obtener más flexibilidad para adaptarse a nuevas condiciones del mercado.
o Mejorar la calidad y eficiencia en los servicios ofrecidos.
o Controlar riesgos.
Para formalizar lo que se espera de la empresa de outsourcing se emplea el Acuerdo de
Nivel de Servicio o SLA (service level agreement). Un acuerdo de nivel de servicio debe
reflejar lo más claramente posible los requisitos de servicio que debe satisfacer el
proveedor de servicios de outsourcing. Un buen nivel de servicio debe incluir los
indicadores y métricas que reflejen la calidad del servicio prestado.
El SLA también debe incluir un esquema de resolución de problemas que permita regresar
a la situación deseada rápidamente y penalizaciones que motiven al proveedor a lograr
los objetivos. Es muy importante que los e indicadores de servicio sean viables de cumplir
por ambas partes para asegurar que la relación entre la empresa y su proveedor de
servicios de outsourcing sea exitosa.
Independientemente de su tamaño, la mayoría de las organizaciones pueden obtener
beneficios, ahorros, mayor focalización, mayor acceso a capacidades y recursos
tecnológicos a través de opciones de outsourcing.
Las principales preocupaciones de una empresa que evalúa alternativas de outsourcing
son:
o Perder control al transferir procesos y recursos a un tercero.
o Perder la confidencialidad de la información.
o Dificultad para contratar y gestionar contratos de outsourcing y recursos externos.
o Obtener menor calidad en el nivel de servicio.
o Perder conocimientos y recursos críticos.
Estas preocupaciones son manejables y deben ser identificadas desde el momento en que
se inicie la evaluación de alternativas de outsourcing para incorporarlos como criterios de
selección y establecer explícitamente esquemas de mitigación de riesgos en los acuerdos
de trabajo con el proveedor de outsourcing.
Los factores críticos de éxito de un outsourcing se centran en asegurar que los máximos
niveles de la organización apoyan la decisión y esquema de outsourcing definido. Para
ello es necesario:
o Comunicar los objetivos del outsourcing a toda la organización.
o Asignar a una persona la responsabilidad de gestionar el outsourcing.
o Mantener comunicación abierta y continua entre la organización y el proveedor
de servicios de outsourcing.
o Establecer claramente los niveles de servicio esperados del proveedor.
o Definir claramente los roles y responsabilidades que ejecutará el proveedor y la
organización.
o Desarrollar y ejecutar un plan de transición.

3.- Alternativas respecto a los datos
Hoy en día, el uso de sistemas gestores de bases de datos está extendido, por lo que no
hay discusión respecto a esta alternativa.
En lo que se refiere al almacenamiento de información en entornos distribuidos, pueden
utilizarse tres alternativas:
1. Base de datos centralizada
2. Base de datos distribuida
3. Bases de datos federadas
3.1 Base de datos centralizada

En este caso, todos los datos se encuentran almacenados en una localización central y
desde todas las localizaciones periféricas se accede por medio de los sistemas de
comunicaciones.
El principal inconveniente de esta alternativa es su dependencia respecto de la
infraestructura de comunicaciones. Sin embargo, debe tenerse en cuenta que tanto el
gasto como la fiabilidad de las comunicaciones hace que esta alternativa sea de las más
utilizadas.
La ventaja principal es la facilidad de gestión de los datos, al estar almacenados en una
sola localización. Esto evita la necesidad de replicaciones y actualizaciones sincronizadas.
Sede
periférica
Sede
periférica
Sede
periférica
BD
Sede
periférica
Sede
central
Sede
Sede periférica
periférica
Base de datos centralizada
3.2 Base de datos distribuida

En este caso, los datos se hallan distribuidos entre las distintas sedes. Cada sede alberga los
datos correspondientes.

La principal ventaja de este caso es que el acceso a los datos de cada sede es más
rápido, si bien se asume que cada sede accede con más frecuencia a los datos propios.
El inconveniente es que el acceso a los datos globales es enormemente complejo puesto
que se necesitan mecanismos de consolidación de los datos distribuidos.
Sede
periférica
Sede
periférica
Sede
periférica
BD
Sede
periférica
Sede
central
Sede
Sede periférica
periférica
Base de datos distribuida
3.3 Bases de datos federadas

Esta alternativa constituye un caso intermedio entre los dos extremos anteriores. Se trata de
tener resúmenes de la base de datos global.
Un primer caso consiste en tener la base de datos completa en la sede central. En cada
sede periférica se tiene un resumen de la base de datos central que se genera
diariamente. Esto asegura que los datos más accedidos por las sedes periféricas están
locales mientras que si se necesitan datos globales o los datos más actualizados, se
acceded a la sede central.

Sede
periférica
Sede
periférica
Sede
periférica
BD
Sede
periférica
Sede
central
Sede
Sede periférica
periférica
Base de datos federada con resúmenes periféricos
Un segundo caso, menos habitual es partir de una base de datos distribuida y generar un
resumen en la sede central. De este modo, no hace falta consolidar los datos para cada
petición, sino solamente para los casos en que se necesiten datos actuales.
Sede
periférica
Sede
periférica
Sede
periférica
BD
Sede
periférica
Sede
central
Sede
Sede periférica
periférica
Base de datos federada con resumen central

4.- Alternativas en software
En el suministro de software pueden distinguirse dos alternativas:
1. Producción de software a medida
2. Compra de paquetes o programas-producto
A su vez, la producción de software a medida puede dividirse en dos casos: que la
producción se realice con medios propios o mediante la contratación con una empresa o
profesionales especializados.
A continuación se describen cada una de las alternativas. Debe tenerse en cuenta que
soluciones intermedias o mixtas son posibles.
4.1 Producción de software a medida

Esta alternativa supone que el software necesario para el sistema informático va a ser
desarrollado a medida, es decir, de acuerdo con los requisitos del sistema.
Entre las ventajas de esta alternativa está que el software así obtenido se adaptará con
bastante precisión a las necesidades de la organización
El principal inconveniente del software a medida está en los plazos, lo que puede retrasar
la puesta en marca del sistema de información hasta hacerlo inviable.
4.1.1 Producción propia del software

Esta alternativa supone la realización del software del sistema informático por personal de
la organización, que cumpla con los requisitos de capacidad y aptitud.
El principal inconveniente de esta alternativa es que requiere que la organización cuente
con los recursos humanos requeridos en el momento de iniciar el proyecto. El
mantenimiento de un plantilla extensa y cualificada supone un elevado coste paa la
organización, por lo que solamente sería posible en organizaciones de calibre medio o
grande.
4.1.2 Contratación externa de software a medida

El software a medida puede ser contratado a una empresa de servicios que se
comprometa a entregar el software acabado y de acuerdo con los requisitos
especificados en el contrato.
La principal ventaja respecto al caso de producción propia del software a medida está en
que puede llevarse a cabo sin necesidad de contar con una plantilla técnica amplia. La
capacidad técnica es ofrecida por la empresa externa.
Sin embargo, este tipos de contratación supone un gasto elevado para la organización,
puesto que no suelen ser económicos este tipo de acuerdos de desarrollo de software a a
medida.
4.2 Compra de paquetes y programas de software

Otra alternativa para la adquisición de software la constituye la compra de software
comercial, ya sea en forma de paquetes o de programas.
4.2.1 Evaluación del software comercial

Las principales ventajas de esta alternativa son el coste y los plazos.

Esta alternativa es la más económica, al no existir costes de desarrollo que deba pagar la
organización, sino que estos costes se dividen entre todos los potenciales compradores del
producto.
Por otra parte, la puesta en marcha del sistema se puede producir en un plazo más corto,
al no existir tiempos de desarrollo. Además, la instalación es más fácil, al ser software ya
empleado por otras organizaciones.
Sin embargo, el inconveniente radica en su generalidad. AL ser un software pensado para
satisfacer las necesidades de un amplio espectro de usuarios, es difícil que se adecue a la
perfección a las necesidades concretas de la organización, por lo que es posible que
hagan falta modificaciones posteriores. Estas modificaciones, en ocasiones, resultan ser
más costosas de lo que pudo haber sido el desarrollo de software a medida.
En determinadas áreas, los paquetes o programas comerciales se encuentran muy
extendidos, desplazando claramente al software a medida, como es en el caso de la
contabilidad, los recursos humanos, la gestión de inventarios.
A este respecto, Roger Pressman resume la estrategia de decisión respecto a los paquetes
o programas comerciales en dos reglas:
1) Si el software comercial satisface los requisitos, hay que adquirirlo. El coste
de la adquisición del software comercial será casi siempre menor que el
coste de desarrollo del software equivalente.
2) Si el software comercial requiere alguna modificación antes de que
pueda ser propiamente integrado en el sistema, hay que evaluar
cuidadosamente la situación. El coste de modificar el software comercial
puede ser a veces mayor que el coste de desarrollar software a medida.
4.2.2 Licencias para productos de software

La adquisición de un programa o paquete comercial supone la cesión del derecho de
uso, también conocida como licencia. Existen varios tipos de licencia, entre los que
destacan los siguientes:
1. Licencia temporal
En este tipo de licencia, por el precio estipulado, el propietario del software cede el
derecho de uso del programa o paquete por un periodo de tiempo fijo, al cabo del
cual, no puede utilizarse.
2. Licencia de uso indefinido
Mediante un pago único en el momento de la cesión, el comprador adquiere el
software que puede utilizar indefinidamente.
3. Licencia de ubicación
Con una sola licencia, todos los ordenadores situados en la misma ubicación dentro de
la organización (estipulada por contrato) pueden utilizar el programa o paquete
comprado.
4. Licencia corporativa
La organización realiza una sola compra y el programa o paquete puede ser utilizado
en cualquier ordenador de la organización.
5. Licencia de red
El programa o paquete puede ser utilizado en cualquier ordenador conectado a la
red.

5.- Alternativas en hardware.
En la adquisición del hardware existen tres alternativas:
1. Compra de equipos nuevos
2. Alquiler de equipos
3. Compra de equipos usados
A su vez, el alquiler puede ser en las dependencias de la organización o fuera de las
dependencias de la organización y, desde el punto de vista financiero, con opción a
compra (leasing) o sin ella.
5.1 Compra de equipos nuevos

Esta alternativa es la habitual en la actualidad, especialmente en equipos pequeños y
medios. Los rpecios actuales de los equipos hacen que sea ésta la alternativa elegida por
la mayoría de las organizaciones.
Es especialmente aconsejable en las siguientes circunstancias:
o En caso que el presupuesto sea suficiente para cubrir la compra de los equipos.
o Cuando la vida esperada del equipo en la organización sea superior al período de
amortización, en torno a los 4 ó 5 años.
o Si no existe peligro de de obsolescencia del equipo o de reducción de su precio.
5.2 Alquiler de equipos

El alquiler está especialmente indicado en las siguientes circunstancias:
o En caso que el presupuesto sea insuficiente para cubrir la compra de los equipos y su
necesidad no permita esperar al próximo ejercicio.
o Cuando la vida esperada del equipo en la organización sea inferior al período de
amortización.
o Si se han identificado riesgos de obsolescencia del equipo o de reducción de su
precio.
El contrato de alquiler debe contener cláusulas de revisión referentes a la actualización o
ampliación del equipo y su coste, la revisión del precio de alquiler con el tiempo, la
resolución anticipada del contrato, etc.
5.2.1 Localización de los equipos

El alquiler de equipos puede referirse tanto a equipos situados en las dependencias de la
organización como a equipos situados en el exterior.
5.2.1.1 Equipos situados en las dependencias

En el caso de equipos situados en las dependencias de la organización, debe tenerse en
cuenta que las tareas de mantenimiento, el aseguramiento de la energía eléctrica y las
medidas de seguridad física y lógica corren a cargo de la propia organización.
El principal inconveniente de esta alternativa es el coste adicional que suponen estas
actividades paralelas. Sin embargo, como ventaja hay que indicar que siempre se puede
tener bajo control el buen funcionamiento del equipo, de modo que la respuesta ante
caída u otros incidente sea rápida.

5.2.1.2 Equipos situados fuera de las dependencias.
En el caso de equipos situados en el exterior, es posible que el equipo pertenezca a la
organización o que se alquile la capacidad de un equipo externo. En el primer caso se
habla de “housing” y el segundo caso es un “hosting”.
En ambos casos, la principal desventaja es la falta de control sobre el funcionamiento, lo
que puede provocar que una incidencia no se corrija lo rápidamente que la organización
necesite. Sin embargo, esta alternativa abarata los costes, puesto que la empresa que
alquila los equipos reparte sus gastos de seguridad, electricidad, etc. entre todos sus
clientes.
5.2.1.2.1 Hosting
El servicio de hosting u hospedaje Web o alojamiento Web es un servicio por el que una
empresa cede espacio en sus servidores a sus clientes para que almacenen sus páginas
Web, correos, etc. La empresa de servicios deberá contar con los sistemas de seguridad
física (no-break) que permitan a esa computadora estar encendida aunque los suministros
de corriente eléctrica normal fallen, esto es, que cuente con SAIs (sistemas de
alimentación ininterrumpida). También debe contar con sistemas de seguridad lógica,
como los cortafuegos o firewalls.
5.2.1.2.2 Housing
Housing es un servicio que permite a las empresas la colocación de sus equipos,
independientemente del hardware y software utilizado, en las instalaciones del
proveedor de servicios. Estas instalaciones deberán estar especialmente acondicionadas
(seguridad, climatización...) y conectadas con enlaces de alta capacidad a Internet.
Este servicio cubre las necesidades de alojamiento, conectividad IP etc. En general, no se
contempla dentro de este servicio la administración, operación y mantenimiento de los
servidores.
El alojamiento de equipamiento informático en estas instalaciones, permitirá a la
organización considerarlo como extensiones virtuales de ésta, permitiendo el ahorro en
costos de red y escalable según requerimientos.
Hay que tener en cuenta en el momento de firmar el contrato el SLA o acuerdo de nivel
de servicio, por el que la empresa de servicios se compromete a cierto nivel. Los SLAs
significan compromisos contractuales de la calidad del servicio prestado al cliente, y se
garantizan mediante penalizaciones por incumplimiento (o premios por mejora de la
calidad). El incumplimiento de un nivel mínimo de calidad, puede suponer la cancelación
inmediata del contrato.
Los SLAs deben asegurar que todos los parámetros (indicadores, pesos, objetivos, umbrales,
etc) puedan ser modificados para mantener vigente su utilidad. Los criterios presentes en
los SLAs deben ser medibles y alcanzables y deben ser revisados periódicamente.
Asimismo, deben contener Planes de Contingencia.
Como elementos típicos de un acuerdo de nivel de servicio (SLA) se citan los siguientes:
o Cobertura del Servicio
o Tiempos de Respuesta
o Tiempos de Resolución
o Número de Incidencias en un periodo
o Disponibilidad del Servicio
o Integridad de los Datos

o Tareas Preventivas
o Frecuencia de los Informes
o Planes de Contingencia
5.2.2 Posibilidades financieras: leasing.

Fundamentalmente, pueden distinguirse dos alternativas financieras en el alquiler de
equipos: el alquiler puro y el alquiler con derecho a compra o leasing. Este último supone
una financiación de la adquisición, lo que añade la posibilidad que tiene el usuario pase a
disponer del equipo en propiedad mediante el pago de una cantidad preestablecida y
variable según el momento de la duración del contrato en el que se ejercite la opción a
compra.
En los casos en que el riesgo de que situaciones provisionales puedan tornarse en
definitivas es grande, es altamente recomendable que todos los contratos de alquiler que
se formalicen sean con opción a compra. Si no, cabe que se produzca el hecho de que a
través de contratos de alquiler sucesivos, se pague varias veces el coste de los equipos.
5.3 Compra de equipos usados

La adquisición de equipos usados está particularmente recomendada en las siguientes
circunstancias:
o Cuando se trata de productos que están en la última fase de su ciclo de
producción. En estos casos la oferta de equipos usados será probablemente
abundante desde un punto de vista cuantitativo, con el consiguiente efecto
favorable en los precios.
o Cuando se trata de adquirir equipos para llevar a cabo una ampliación de un
sistema que se prevé sustituir en breve plazo.
o Como solución transitoria hasta la entrega del dispositivo que definitivamente va a
quedar instalado.
o Cuando la diferencia de costes entre el equipo nuevo y el usado es significativa.
A la hora de adquirir un equipo usado conviene tener en cuenta las siguientes
consideraciones:
o Saber si el fabricante del equipo o un suministrador de mantenimiento
independiente está dispuesto a mantenerlo igual que si fuera nuevo. A este
respecto, algunos fabricantes de ordenadores suministran una carta de acuerdo
de mantenimiento por la que confirman su disponibilidad a mantener el equipo en
cuestión.
o Asegurarse de que la empresa suministradora dispone realmente del equipo usado
que ofrece. Algunas veces ocurre que las empresas que se dedican a esta
actividad esperan a tener el pedido para acudir al mercado y tratar de obtener el
equipo. De hecho, en ocasiones una pieza particular de un equipo es tan escasa,
que varios intermediarios a la vez ofrecen la misma pieza al mismo cliente. Por ello,
si no se han tomado las debidas precauciones, podemos vernos defraudados en el
último momento, al fracasar el suministrador en encontrar el equipo en el mercado
de segunda mano.

6.- Criterios. Evaluación de alternativas.
La valoración de alternativas de decisión utiliza distintas técnicas. La más extendida es la
que utiliza la teoría de la decisión multicriterio discreta (DMD). Esta teoría se basa en la
utilización de criterios que, una vez ponderados, sirvan para evaluar cada una de las
alternativas y, al final, poder tomar la decisión, es decir, la selección de la mejor
alternativa.
Los criterios deben ser escogidos con cuidado, teniendo en cuenta las necesidades de la
organización. Los criterios atenderán tanto a medidas objetivas como a medidas
subjetivas. Entre las primeras pueden incluirse las características del equipo en sí: potencia
de cálculo, memoria, etc. Las características subjetivas incluyen las valoraciones dadas al
fabricante: reputación, capacidad de suministro, …
A cada uno de los criterios se le asigna un peso, que representa la importancia de dicho
criterio en la decisión final. Esta fase es de una importancia máxima, pues del peso
dependerá que un criterio prevalezca y dé lugar a la selección de una determinada
alternativa. Esta tarea requiere de la experiencia de las personas encargadas de la
selección de alternativas, al tratarse de una asignación subjetiva.
El método más empleado para la selección de alternativas, basado en la teoría de la
decisión multicriterio discreta, es el método de la ponderación lineal.
En este método deben seguirse las siguientes fases:
1. Elección de criterios
2. Asignación de pesos
3. Valoración de alternativas
En la elección de criterios han de tenerse en cuenta las necesidades de la organización
para la selección de las alternativas. Los criterios (ck, k=1..n) han de contribuir directa o
indirectamente a la consecución de los objetivos fijados.
Según su participación en el objetivo, debe asignarse un peso (pk)a cada uno de los
criterios anteriormente identificados.
Para cada una de las alternativas (Ai, i=1…m), debe darse el valor de cada criterio (vik).
El método de la ponderación lineal define la función de utilidad como una función lineal
de los valores de cada criterio.
U(Ai) = vi1· p1 + … + vin· pn = ¦ vik· pk
La alternativa elegida será aquella cuya función de utilidad sea mayor.
7.- Análisis de viabilidad

El análisis de la viabilidad de un proyecto informático debe responder a la pregunta de si
se debe llevar a cabo el proyecto y en caso de decidir su ejecución, cuál de las posibles
alternativas se elige.
En los capítulos anteriores se ha visto cuáles son las distintas alternativas a tener en cuenta
en un proyecto informático, en particular en lo respectivo a recursos humanos,
procedimientos, datos, software y hardware. También se han visto distintos métodos para
la valoración de alternativas.

En este capítulo se verá el proceso de realización de un estudio de viabilidad. En la
metodología MÉTRICA Versión 3 se define un proceso principal EVS (Estudio de la
Viabilidad del Sistema).
Con el fin de implantar un sistema de información comercial, es necesario llevar a cabo un

estudio de viabilidad.
En el estudio de viabilidad se siguen estos pasos principales:
1. Análisis del sistema actual
2. Diseño de sistemas.
3. Selección de alternativas.
El primer paso se enfoca en el análisis de sistemas que es una revisión completa y

comprensiva del sistema actual. Este análisis le permite al equipo de realización del estudio
de viabilidad hacer comparaciones válidas entre el sistema actual y las muchas
alternativas de sistemas viables, proporcionando con ello una base para la preparación
del informe de investigación exploratoria dirigido a la alta dirección.
Una vez que se ha tomado la decisión de implantar un nuevo sistema de información para
el negocio, se especifican los detalles del sistema. El segundo paso del estudio del
viabilidad es el diseño del sistema en esta fase son necesarias la imaginación y la
creatividad; de otra manera algunas de las debilidades básicas y de los problemas
relacionados del sistema existente serán duplicados inconscientemente por el grupo de
procesamiento de datos.
La viabilidad del proyecto se examina en tres áreas, que se describen a continuación.
7.1 Viabilidad operacional

Se refiere al hecho de que si funcionará o no el sistema si este se llega a desarrollar,
preguntas claves aquí son:
¿Existe apoyo suficiente para el proyecto por parte de la Dirección?, ¿Y por parte
de los usuarios?
Los métodos que actualmente se usan en la empresa, ¿son aceptados por los
usuarios?
¿Los usuarios han participado en la planificación y desarrollo del proyecto?,
¿Cómo lo han hecho?
¿El sistema propuesto causará perjuicios?
¿Producirá resultados pobres en alguna área?
¿Se perderá control en alguna área específica?
¿Se perderá la facilidad de acceso a la información?
¿La productividad de los empleados será menor después de instalado el sistema?
¿Los clientes se verán afectados por la implantación?
7.2 Viabilidad Técnica

La viabilidad técnica se resume en las siguientes preguntas:
¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?

¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos
requeridos para usar el nuevo sistema?
¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar
el número y ubicación de los usuarios?
Si se desarrolla el sistema, ¿se puede crecer con facilidad?
¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y
seguridad de los datos?
7.3 Viabilidad financiera y económica

Un sistema puede ser viable desde el punto de vista técnico y operacional, pero si no es
viable económicamente para la organización no puede ser implantado. Las cuestiones
económicas y financieras formuladas por los analistas deben incluir:
El coste de llevar a cabo la investigación completa de sistemas
El coste del hardware y software para la aplicación
Beneficios en la forma de reducción de costes o de menos errores costesos
El coste si nada sucede (si el proyecto no se lleva a cabo)

£
Tema II.II.10. Diseño orientado a objetos: Concepto. Elementos:

objetos, clases, herencia. Ventajas e
inconvenientes. El lenguaje de modelización
unificado (UML). El modelo CORBA.
Índice
1.- DISEÑO ORIENTADO A OBJETOS ..................................................................................................... 3
1.1 Historia ........................................................................................................................................... 3
1.2 Concepto ..................................................................................................................................... 5
1.3 Elementos: Objetos, Clases, Métodos, Herencia.................................................................... 5

1.3.1 Objeto....................................................................................................................................................5
1.3.2 Clase ......................................................................................................................................................5
1.3.3 Métodos ................................................................................................................................................6
1.4 Fundamentos ............................................................................................................................... 6

1.4.1 Abstracción ..........................................................................................................................................6
1.4.2 Modularidad.........................................................................................................................................7
1.4.3 Encapsulamiento.................................................................................................................................7
1.4.4 Jerarquía ...............................................................................................................................................8
1.4.5 Polimorfismo..........................................................................................................................................8
1.5 Taxonomía de los Lenguajes Orientados a Objetos.............................................................. 9
1.6 Características adicionales de los Lenguajes Orientados a Objetos ................................. 9
1.7 Ventajas e inconvenientes ......................................................................................................10
2.- EL LENGUAJE DE MODELIZACIÓN UNIFICADO (UML)................................................................... 11
2.1 Concepto ...................................................................................................................................11
2.2 Visión general de UML ..............................................................................................................11

2.2.1 Utilidad de UML..................................................................................................................................11
2.2.2 Usos de UML........................................................................................................................................12
2.3 Historia .........................................................................................................................................12
2.4 Ventajas de UML........................................................................................................................13
2.5 Inconvenientes de UML ............................................................................................................14
2.6 Elementos de UML .....................................................................................................................14

2.6.1 Bloques de construcción de UML...................................................................................................14
2.6.1.1 Elementos de Modelado ......................................................................................................14
2.6.1.1.1 Elementos Estructurales ..............................................................................................................14
2.6.1.1.2 Elementos de Comportamiento ...............................................................................................16

£
2.6.1.1.3 Elementos de Agrupación.........................................................................................................16

2.6.1.1.4 Elementos de Anotación ...........................................................................................................17
2.6.1.2 Relaciones ...............................................................................................................................17
2.6.1.3 Diagramas UML.......................................................................................................................18
2.6.1.3.1 Elementos Comunes a Todos los Diagramas..........................................................................18
2.6.1.3.2 Diagramas de Estructura Estática (Diagrama de clases) ....................................................18
2.6.1.3.3 Diagrama de Casos de Uso ......................................................................................................21
2.6.1.3.4 Diagramas de Interacción ........................................................................................................22
2.6.1.3.5 Diagrama de Estados .................................................................................................................24
2.6.2 Mecanismos comunes de UML .......................................................................................................24
3.- EL MODELO CORBA........................................................................................................................ 26
3.1 Introducción ...............................................................................................................................26
3.2 La Arquitectura de Administración de Objetos (OMA) ......................................................27

3.2.1 Servicios de objeto ............................................................................................................................28
3.2.2 Facilidades comunes........................................................................................................................28
3.2.3 Interfaces de Dominio ......................................................................................................................28
3.2.4 Interfaces de Aplicación .................................................................................................................28
3.3 EL Mediador de Peticiones de Objeto (ORB) .......................................................................29

3.3.1 El cliente ..............................................................................................................................................30
3.3.2 ORB (Object Request Broker) ..........................................................................................................30
3.3.3 Interfaz ORB ........................................................................................................................................30
3.3.4 Lenguaje de Definición de Interfaces (IDL)..................................................................................31
3.3.5 IDL Stubs e IDL Skeletons...................................................................................................................31
3.3.6 Repositorio de Interfaces (IR) ..........................................................................................................31
3.3.7 DDI y DSI ..............................................................................................................................................32
3.3.8 Adaptador de Objetos.....................................................................................................................32
3.3.9 Repositorio de Implementación .....................................................................................................33
3.3.10 Protocolos del ORB............................................................................................................................33
3.4 Implementaciones de CORBA en el mercado ....................................................................34
3.5 Un Sistema Distribuido con CORBA.........................................................................................34

£
1.- Diseño orientado a objetos

La tecnología orientada a objetos se define como una metodología de diseño de software
que modela las características de objetos reales o abstractos por medio del uso de clases
y objetos. Hoy en día, la orientación a objetos es fundamental en el desarrollo de software.
1.1 Historia
En un sentido general se puede considerar la Orientación a Objetos (OO) como un marco
para la ingeniería del software basado en objetos y clases. Abarca desde los principios del
análisis de un problema hasta el final de su implementación y su dominio de aplicación
también es muy amplio. Según varios autores, el interés por la OO surgió en el contexto de
la crisis del software de los años 70 (la falta de reusabilidad de software). Al hablar de la
OO, se suelen identificar las siguientes ventajas:
Desarrollo rápido de sistemas.
Mejora en la calidad y legibilidad del código.
Facilidad de mantenimiento.
Aprovechamiento del poder de los LPOO.
Reusabilidad de software y diseños.
Producción de sistemas más resistentes al cambio.
La Programación Orientada a Objetos (POO) y los Lenguajes de Programación Orientada
a Objetos (LPOO) juegan un papel importante dentro de las tecnologías OO. Según la
literatura, el término objeto emergió paralelamente en varios campos de la Informática a
principios de los años 70, para hacer referencia a nociones superficialmente distintas
aunque relacionadas. La identificación de la importancia de la composición de sistemas
en niveles de abstracción, la ocultación de información y el desarrollo de mecanismos de
tipos de datos abstractos en los años 70 tuvieron una gran influencia en el desarrollo de la
POO, aunque existe cierta polémica sobre cómo exactamente estos avances dieron lugar
a lo que hoy en día se considera como POO. El LPOO Simula apareció en 1962 (y más
tarde Simula67 en 1967) y, aunque no fue muy utilizado, ha sido reconocido como el
primer LPOO, incorporando los conceptos de clase y objeto.
El concepto de POO propiamente dicho fue presentado por Alan Kay, uno de los
inventores de Smalltalk (el primer LPOO popular), algunos años más tarde:
Un objeto almacena datos y se le pueden hacer peticiones.
Un programa es un conjunto de objetos que intercambian mensajes.
Cada objeto tiene su propia memoria que está compuesta por otros objetos.
Cada objeto tiene un tipo de mensajes que puede recibir y procesar.
Todos los objetos de un cierto tipo pueden procesar los mismos mensajes.
Se trata de una caracterización muy general que no se puede aplicar a muchos de los
LPOO más utilizados hoy en día. Smalltalk tenía estas características y fue concebido con
el objetivo de ser un LPOO dinámico, que permitiera la adición de nuevas clases, objetos y
comportamiento sobre la marcha. En las actas del congreso HOPL II editadas en 1993 por
la ACM (Association of Computing Machinery), Kay definió la POO en términos de una
célula que permite el flujo de información en las dos direcciones, pero en la cual lo que

£
está dentro está oculto desde fuera. En 1985 apareció el LPOO Eiffel, diseñado para
mejorar la productividad y calidad de programas OO, pero no fue muy utilizado.
Para que la POO se estableciera como un paradigma era necesario que los
programadores lo adoptaran. Por eso fue muy efectiva la modificación de un LP ya
existente para incorporar los conceptos (y beneficios) de la POO, sin perder la posibilidad
de reutilizar código fuente, como ocurrió con C++ (que es una extensión de C que incluye
los conceptos de OO). Otros lenguajes de programación han sido expandidos también
para incorporar estos conceptos: Modula2 se convirtió en Modula3, Ada en Ada95, Lisp en
CLOS (Common Lisp Object System, vía Flavors), COBOL en Object COBOL, etc. Como
ejemplos de LPOO de nueva creación se pueden destacar Python, Java y C#.
Actualmente se pueden identificar unos 140 LPOO que se usan de alguna forma u otra.
LISP Flavors CLOS
LOOPS
Ada 9X
Pascal Ada
Eiffel
Object Pascal
ALGOL SIMULA Smalltalk Smalltalk 80 Smalltalk V
Objective C
C
Java
C ++
Otra manera de ver la POO es como la evolución natural de la programación imperativa,

desde la programación sin estructura, pasando por la programación por procedimientos y
modular. En primer lugar, la programación sin estructura es la más sencilla y cada
programa consiste en una secuencia de instrucciones que operan sobre datos globales o
comunes a todas las partes del programa. Lo que ocurre es que, según va creciendo el
programa, van surgiendo problemas. Por ejemplo, si se necesita la misma secuencia de
instrucciones en varias partes del programa, hay que copiarla. Para evitar este problema,
se empezaron a extraer estas secuencias, a darles un nombre, y a ofrecer una técnica
para llamarlas y devolver el flujo de control desde ellas al programa principal junto con los
resultados. Así aparecieron los procedimientos y funciones y la programación por
procedimientos. Con la incorporación del paso de parámetros y procedimientos dentro de
otros, se podían escribir programas con más estructura y menos probabilidades de errores.
Así, en vez de ver un programa como una secuencia de instrucciones, se podía
contemplar como una secuencia de llamadas a procedimientos. La extensión natural de
este tipo de programación consistió en agrupar en módulos procedimientos comunes a
varios programas, y así surgió la programación modular. En ella cada módulo tiene sus
propios datos y estado, que se modifican con las llamadas al módulo. Por último, la POO
soluciona algunos de los problemas de la programación modular: puede haber

£
simultáneamente múltiples versiones de un mismo objeto y cada una es responsable de su

propia creación y destrucción.
1.2 Concepto
La orientación a objetos es un paradigma de programación que facilita la creación de
software de calidad por sus factores que potencian el mantenimiento, la extensión y la
reutilización del software generado bajo este paradigma.
La programación orientada a objetos trata de amoldarse al modo de pensar del hombre y
no al de la máquina. Esto es posible gracias a la forma racional con la que se manejan las
abstracciones que representan las entidades del dominio del problema, y a propiedades
como la jerarquía o el encapsulamiento.
El elemento básico de este paradigma no es la función (elemento básico de la
programación estructurada), sino un ente denominado objeto. Un objeto es la
representación de un concepto para un programa, y contiene toda la información
necesaria para abstraer dicho concepto: los datos que describen su estado y las
operaciones que pueden modificar dicho estado, y determinan las capacidades del
objeto.
1.3 Elementos: Objetos, Clases, Métodos, Herencia
1.3.1 Objeto
Un objeto es una unidad de software conformada por atributos y métodos específicos.
El objeto, es el concepto principal sobre el cual se fundamenta la tecnología orientada a
objetos. Un objeto puede ser visto como una entidad que posee atributos y efectúa
acciones.
En el mundo real podemos encontrar cientos de ejemplos que cumplen con esta
definición, algunos de ellos son: una bicicleta, un automóvil, una persona, una
computadora, etcétera.
Estos objetos son casos particulares de entidades llamadas clases en donde se definen las
características comunes de tales objetos. Veamos el caso particular del objeto automóvil,
podemos mencionar como atributos de éste: el modelo, el color, la marca, el número de
placas, entre otros. Algunas acciones que es capaz de realizar un automóvil son: ir marcha
atrás, girar, acelerar y cambiar de marcha. Este objeto automóvil es una instancia
particular de la entidad automóvil. En términos de la programación orientada a objetos, se
dice que todo objeto tiene un estado (atributos) y un comportamiento (acciones). La
programación orientada a objetos nos permite modelar estos objetos del mundo real en
objetos de software de forma eficaz. Un objeto de software mantiene sus atributos o
estado en variables e implementa las acciones o comportamientos por medio de métodos
o funciones.
Supongamos que queremos desarrollar una aplicación que simule un vehículo. Tendríamos
entonces un objeto vehículo constituido por variables en las cuales podríamos almacenar
número de serie, color, la velocidad actual, etcétera. Aunado a esto, tendríamos un
conjunto de funciones que implementaran las acciones para frenar, girar, cambiar de
marcha, etc.
1.3.2 Clase
Una clase es un molde o prototipo en donde se definen los atributos (variables) y las
acciones (métodos) comunes de una entidad.

£
Éste es el paradigma que propone la programación orientada a objetos: la abstracción de

los elementos que constituyen a un objeto del mundo físico; esto es, atributos y
comportamiento, y la representación de éstos elementos por medio de objetos de
software formados por variables y métodos que permitan la manipulación de tales
variables. Cabe mencionar que además de representar los objetos físicos del mundo real
por medio de objetos, también podemos modelar objetos abstractos, por ejemplo las
acciones de un usuario al interactuar con la máquina. Como observaremos más adelante,
algunas de las ventajas de la tecnología orientada a objetos son la reutilización de
objetos, y la facilidad de comprensión de los programas.
1.3.3 Métodos
Los métodos especifican la forma en que se controlan los datos de un objeto. Los métodos
en un tipo de objeto sólo hacen referencia a la estructura de datos de ese tipo de objeto.
No deben tener acceso directo a las estructuras de datos de otros objetos. Para utilizar la
estructura de datos de otro objeto, deben enviar un mensaje a éste. El tipo de objeto
empaca juntos los tipos de datos y su comportamiento.
Un objeto entonces es una cosa cuyas propiedades están representadas por tipos de
datos y su comportamiento por métodos.
Un método asociado con el tipo de objeto factura podría ser aquél que calcule el total
de la factura. Otro podría transmitir la factura a un cliente. Otro podría verificar de manera
periódica si la factura ha sido pagada y, en caso contrario, añadir cierta tasa de interés.
1.4 Fundamentos
La POO se basa en una serie de cualidaes que tienen los objetos de software. Los
elementos más importantes que deben tener los objetos de software, para cumplir con el
paradigma de orientación a objetos son:
Abstracción.
Modularidad.
Encapsulamiento.
Jerarquía.
Polimorfismo.
A continuación se describe cada uno de ellos.
1.4.1 Abstracción
La abstracción es el proceso en el cual separamos las propiedades más importantes de un
objeto de las que no lo son. Es decir, por medio de la abstracción definimos las
características esenciales de un objeto del mundo real, los atributos y comportamientos
que lo definen como tal, para después modelarlo en un objeto de software.
En el proceso de abstracción no debemos preocuparnos por la implementación de cada
método o atributo, solamente debemos definirlo de forma general. Por ejemplo,
supongamos que deseamos escribir un programa para representar el sistema solar. Por
medio de la abstracción, podemos ver a este sistema como un conjunto de objetos.
Algunos de estos objetos son los planetas, que tienen un estado dado por sus
características físicas: tamaño, masa,... Estos objetos tendrán también comportamientos:
translación y rotación, como los más evidentes.

£
Visualizar las entidades que deseamos trasladar a nuestros programas, en términos

abstractos, resulta de gran utilidad para un diseño óptimo de nuestro software, ya que nos
permite comprender más fácilmente la programación requerida.
En la tecnología orientada a objetos la herramienta principal para soportar la abstracción
es la clase. Podemos definir una clase como una descripción genérica de un grupo de
objetos que comparten características comunes, dichas características se especificadas
en sus atributos y comportamientos. En otras palabras, una clase es un molde o modelo en
donde se especifican las características que definen a un objeto de manera general, a
partir de una clase pedemos definir objetos particulares. En programación orientada a
objetos se dice que un objeto es una instancia de la clase, es decir un objeto, es un caso
particular del conjunto de objetos que comparten características similares, definidas en la
clase.
Un ejemplo servirá para clarificar estos conceptos. Definamos a la clase persona, esta
clase tendrá ciertos atributos, por ejemplo edad, sexo y nombre entre otros. Las acciones o
comportamientos que podemos definir para esta clase son, por ejemplo, respirar, caminar,
comer, etc. Éstas son, para nuestro caso, las características que definen a nuestra clase
persona. Un objeto instanciado de esta clase podría ser Pedro González, de sexo
masculino y de 30 años de edad, que está ahora andando. Estos atributos son conocidos
formalmente en programación orientada a objetos como variables de instancia porque
contienen el estado de un objeto particular en un momento dado, en este caso Pedro
González. Así mismo, los comportamientos son llamados métodos de instancia porque nos
muestran el comportamiento de un objeto particular de la clase.
1.4.2 Modularidad
Dentro de la programación orientada a objetos, la modularidad juega un papel muy
importante. Una vez que hemos representado una situación del mundo real en un
programa, obtenemos como resultado un conjunto de objetos de software que
constituyen la aplicación. La modularidad, nos permite poder modificar las características
de la clase que definen a un objeto, de forma independiente de las demás clases en la
aplicación. En otras palabras, si nuestra aplicación puede dividirse en módulos separados,
normalmente clases, y estos módulos pueden compilarse y modificarse sin afectar a los
demás, entonces dicha aplicación ha sido implementada en un lenguaje de
programación que soporta la modularidad.
La tecnología orientada a objetos nos brinda esta propiedad para hacer uso de ella en el
software que desarrollemos.
1.4.3 Encapsulamiento
También referido como ocultamiento de la información, el encapsulamiento es la
propiedad de la orientación a objetos que nos permite asegurar que la información de un
objeto le es desconocida a los demás objetos en la aplicación. Es muy frecuente referirse a
los objetos de software como cajas negras, esto se debe principalmente a que no
necesitamos, dentro de la programación orientada a objetos, saber como esta
instrumentado un objeto para que este interactúe con los demás objetos. Generalmente
una clase se define en dos partes, una interfaz por medio de la cual los objetos que son
instanciados de la misma interactúan con los demás objetos en la aplicación, y la
implementación de los miembros de dicha clase (métodos y atributos).
Una aplicación orientada a objetos esta constituida, como mencionamos anteriormente,
por módulos. Estos módulos se implementan mediante clases, las cuales representan,
generalmente, abstracciones de objetos del mundo real. Es por medio del
encapsulamiento que podemos definir los atributos y los métodos de una clase para que

£
los objetos que se instancian de ésta trabajen como unidades independientes de los
demás objetos con los que interactúan.
Por otra parte, con el encapsulamiento ganamos modularidad, y además protegemos a
los objetos de ser manipulados de forma inadecuada por objetos externos.
1.4.4 Jerarquía
Una vez que se ha definido una clase, por ejemplo la clase bicicleta, con sus atributos y
métodos, tal vez necesitemos definir una nueva clase específica para las bicicletas de
carreras.
Es obvio que esta nueva clase compartirá elementos en común con la clase bicicleta, es
decir, la clase bicicleta de carreras será un subconjunto de la clase bicicleta.
La tecnología orientada a objetos permite definir jerarquías entre clases y jerarquías entre
objetos. Las dos jerarquías más importantes que existen son la jerarquía “es un” que precisa
la generalización y especificación entre clases y la jerarquía “es parte de” en la cual se
delimita la agregación de objetos.
Comúnmente, a la jerarquía “es un” se le conoce como herencia. La herencia simple es la
propiedad que nos permite definir una clase nueva en términos de una clase ya existente.
Regresando al ejemplo, si podemos decir que una bicicleta de carreras “es una” bicicleta,
entonces podemos definir a la clase bicicleta de carreras a partir de la clase bicicleta.
Existirán casos en los cuales se necesite definir una clase a partir de dos o más clases
preexistentes, en este caso estaremos hablando de herencia múltiple.
En cuanto a la jerarquía de agregación, también conocida como inclusión, podemos
decir que se trata del agrupamiento lógico de objetos relacionados entre si dentro de una
clase.
Supongamos que tenemos que definir a la clase automóvil, pero además hemos definido
ya la clase volante. Si podemos expresar la oración, un volante “es parte de” un automóvil,
entonces podemos instanciar un objeto de la clase volante, para definir a la clase
automóvil.
En este caso, se dice que automóvil es una agregación y volante es un agregado de
automóvil.
1.4.5 Polimorfismo
Muchas veces es necesario que un mismo comportamiento o acción se realice de
diferentes maneras. Por ejemplo, supongamos que deseamos implementar a la clase
mamíferos, supongamos también que uno de los métodos que deseamos implementar
para esta clase, es el que permita a tales mamíferos desplazarse de forma natural. Nos
encontraremos entonces con que para algunos mamíferos el desplazamiento se realizará
por medio de caminar, como es en el caso de las personas, para otros el desplazamiento
natural será nadar, como en el caso de las ballenas y delfines e inclusive para otros, el
desplazamiento se logrará por medio de volar, como sucede con los murciélagos. En otras
palabras, un mismo comportamiento, en este caso el desplazamiento, puede tomar
diferentes formas.
Dentro de la programación orientada a objetos puede modelarse esta situación del
mundo real en objetos de software, gracias al polimorfismo. El polimorfismo es la propiedad
por la cual una entidad puede tomar diferentes formas. Generalmente está entidad es
una clase, y la forma en que se consigue que tome diferentes formas es por medio de
nombrar a los métodos de dicha clase con un mismo nombre pero con diferentes
implementaciones.

£
1.5 Taxonomía de los Lenguajes Orientados a Objetos

Una clasificación para los lenguajes de programación con respecto a la orientación a
objetos fue creada por Wegner, dicha clasificación se constituye de la siguiente forma:
Basados en objetos Basados en clases Orientación a Objetos

Si un lenguaje de
Si la sintaxis y semántica de Si un lenguaje esta basado en programación soporta
lenguaje soportan las objetos y además soporta clases, objetos, clases y además
características de objetos se dice que esta basado en permite la jerarquía de
que hemos mencionado. clases. dichas clases, entonces se
dice que es un lenguaje de
programación orientado a
objetos.
Esta clasificación es la que prevalece actualmente. En ella se establece claramente que

para que un lenguaje de programación sea considerado orientado a objetos éste debe
soportar la creación de clases y la herencia.
Java es actualmente uno de los lenguajes de programación, que cumple perfectamente
con los requisitos de la orientación a objetos. Delphi, Simula, Smalltalk, son también
considerados lenguajes orientados a objetos.
Java puede ser visto como el resultado de una mezcla de C++ y Smalltalk, tiene la sintaxis
de C++, lo que lo hace relativamente fácil de aprender, si es que se está familiarizado con
C++, una de las características que lo hace más robusto que C++, es que no tiene
punteros, que son causa común de errores en el desarrollo de aplicaciones con este
lenguaje. Como en el caso de Smalltalk, Java tiene recolección de basura, una
capacidad que libera al programador de definir funciones de asignación y desalojo de
estructuras en memoria.
1.6 Características adicionales de los Lenguajes Orientados a Objetos

Además de las características que mencionamos anteriormente como esenciales de los
lenguajes de programación orientados a objetos, es deseable que éstos cumplan también
con las siguientes:
Tipificación fuerte. Esto es, que durante la fase de diseño e implementación se declare
qué tipo de datos soportará cada variable.
Manejo de excepciones. Dentro de la misma definición del lenguaje se deberá
establecer la forma de detectar y manipular excepciones que puedan surgir durante
la ejecución de un programa.
Paso de mensajes. Es conveniente que el lenguaje soporte paso de mensajes entre
módulos de manera bidireccional.
Generalidad. Se refiere principalmente a que las clases se definan lo más
generalizadas posible para que sean fácilmente reusables. Para generar este tipo de
clases, normalmente se definen parámetros formales que son instanciados por
parámetros reales.
Multitarea. Es conveniente que el lenguaje permita la creación de procesos que se
ejecuten de forma simultánea independientemente del sistema operativo.
Persistencia. Los objetos deben poder permanecer, si así se desea, después de la
ejecución de un programa.

£
Datos compartidos. Los objetos pueden necesitar referirse a la misma localidad de

memoria (memoria compartida) o bien comunicarse mediante mensajes.
1.7 Ventajas e inconvenientes

Entre las innumeras ventajas, podemos mencionar:
Flexibilidad. Si partimos del hecho que mediante la definición de clases establecemos
módulos independientes, a partir de los cuales podemos definir nuevas clases,
entonces podemos pensar en estos módulos como bloques con los cuales podemos
construir diferentes programas.
Reusabilidad. Una vez que hemos definido a la entidad persona para utilizarla en una
aplicación de negocios, por mencionar un ejemplo, y deseamos construir a
continuación una aplicación, digamos de formación, en donde requerimos definir la
misma entidad persona, no es deseable volver a escribir la definición para la entidad
persona. Por medio de la reusabilidad podemos utilizar una clase definida previamente
en las aplicaciones que nos sea conveniente. Es claro que la flexibilidad con la que se
definió la clase va a ser fundamental para su reutilización.
Mantenibilidad. Las clases que conforman una aplicación, vistas como módulos
independientes entre sí, son fáciles de mantener sin afectar a los demás componentes
de la aplicación.
Extensibilidad. Gracias a la modularidad y a la herencia una aplicación diseñada bajo
el paradigma de la orientación a objetos puede ser fácilmente extensible para cubrir
necesidades de crecimiento de la aplicación.
A pesar de que las ventajas de la programación orientada a objetos superan a las
limitaciones de la misma, podemos encontrar algunas características no deseables en
ésta:
Limitaciones para el programador. A pesar de que la tecnología orientada a objetos
no es nueva, un gran porcentaje de programadores no están familiarizados con los
conceptos de dicha tecnología. En otras palabras, la lógica de la programación
estructurada sigue siendo predominante en la mayoría de los desarrolladores de
software. La programación orientada a objetos requiere una lógica de pensamiento
totalmente diferente a la lógica comúnmente utilizada para la programación
estructurada.
Tamaño excesivo en las aplicaciones resultantes. Hoy en día, la gran mayoría de los
equipos de cálculo cuentan con capacidades tanto de almacenamiento como de
memoria lo suficientemente altas para ejecutar la mayoría de las aplicaciones que
puedan desarrollarse con la tecnología orientada a objetos, aunque puedan existir
casos en los que lo anterior no se cumple.
Una de las desventajas de la programación orientada a objetos es que cuando se
heredan clases a partir de clases existentes se heredan de forma implícita todos los
miembros de dicha clase aun cuando no todos se necesiten, lo que produce
aplicaciones muy grandes que no siempre encajan en los sistemas con los que se
disponga.
Velocidad de ejecución. Esto tiene que ver, en cierto modo, con el punto anterior, una
aplicación innecesariamente pesada en muchas ocasiones es más lenta de ejecutar
que una aplicación conformada únicamente por los módulos necesarios.

£
2.- El Lenguaje de Modelización Unificado (UML)
2.1 Concepto
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y
documentar los elementos que forman un sistema software orientado a objetos. Se ha
convertido en el estándar de facto de la industria, debido a que ha sido concebido por los
autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar
Jacobson y Jim Rumbaugh.
Estos autores fueron contratados por la empresa Rational Software Co. para crear una
notación unificada en la que basar la construcción de sus herramientas CASE. En el
proceso de creación de UML han participado, no obstante, otras empresas de gran peso
en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de
analistas y desarrolladores.
Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y
debido a que incorpora las principales ventajas de cada uno de los métodos particulares
en los que se basa: Booch, OMT y OOSE. UML puso fin a las llamadas guerras de métodos
que se habían mantenido a lo largo de los 90, en las que los principales métodos sacaban
nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusionó la
notación de estas técnicas para formar una herramienta compartida entre todos los
ingenieros software que trabajan en el desarrollo orientado a objetos.
El objetivo principal cuando se empezó a gestar UML era posibilitar el intercambio de
modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello
era necesario definir una notación y semántica común.
El estándar UML no define un proceso de desarrollo específico, tan solo se trata de una
notación.
2.2 Visión general de UML

Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representación conceptual y física de un sistema, por lo tanto es un lenguaje estándar
para los planos del software.
2.2.1 Utilidad de UML

UML es un lenguaje para:
1. Visualizar
Un programador cuando esta modelando tiene que pensar en:
Primero, la comunicación de esos modelos conceptuales a otros está sujeta a
errores a menos que cualquier persona implicada hable del mismo lenguaje.
Segundo, que el software no puede entender a menos que se construyan modelos
que trasciendan el lenguaje de programación textual.
Tercero, si el desarrollador que escribió el código no dejó documentación sobre los
modelos, esa información se perderá y será parcialmente reproducible a partir de
la implementación.
UML es algo más que un simple montón de símbolos gráficos, en cada símbolo hay una
semántica definida.
2. Especificar

£
Especificar significa construir modelos precisos, no complejos. Y UML cubre las

especificaciones de todas las decisiones de análisis, diseño e implementación que
deben realizarse al desarrollar un sistema de gran cantidad de software.
3. Construir
Los modelos de UML pueden conectarse de forma directa a gran variedad de
lenguajes de programación. Esta correspondencia permite ingeniería directa: la
generación de código a partir de un modelo UML en un lenguaje de programación.
También se puede reconstruir el modelo a partir de una implementación.
4. Documentar
Una organización de software que trabaje bien produce:
Requisitos
Arquitectura
Diseño
Código fuente
Planificación de proyectos
Pruebas
Prototipos
Versiones
UML cubre la documentación de la arquitectura y proporciona requisitos y pruebas y
las actividades de planificación de proyectos.
2.2.2 Usos de UML

UML se utiliza en los siguientes campos:
Sistemas de información de empresas
Bancos y servicios financieros
Telecomunicaciones
Transporte
Defensa / industrias aeroespacial
Comercio
Electrónica médica
Ámbito científico
Servicios distribuidos basados en la Web
2.3 Historia
Durante 1996 importantes organizaciones comprendieron que el desarrollo del UML sería
una estrategia para su negocio. El OMG (Object Management Group) público una
propuesta con un catalogo del conjunto de compañías que iban a cooperar para el
desarrollo del UML. Rational establece el consorcio de socios UML con otras compañías.
Este consorcio se dedica a la definición y desarrollo del UM 1.0. Las compañías que lo
forman son: Digital Equipment Cop.; HP; i-Logix; IntelliCorp; IBM; ICON Computing; MCI
Systemhouse; Microsoft; Oracle; Rational Software; TI y Unisys. El UML 1.0 fue presentado por
OMG en enero de 1997.

£
A principios de 1997 IBM&ObjecTime, Platinum Technology, Ptech, Taskon&Reich

Technologis y SoftTeam también suministran sus ideas a OMG. Se pública el UM 1.1 con las
nuevas idas suministradas por estas últimas compañías. Esta nueva versión aclara algunos
conceptos semánticos e incorpora algunos nuevos. A continuación se puede ver el
camino que ha seguido el desarrollo del UML:
In du strialization
P u blication of U M L 1 .1 S ep tem ber ´97 U M L 1.1

S tan d ard ization
P ub licatio n o f
U M L 1.0, Ja n ´97 U M L 1.0
pu blic Jun e ´9 6 & O ct ´96 U M L 0.9 & 0 .91

feedb ack
U M L P artn ers’ U n ification
O O P SL A ´95 U n ified M eth od 0 .8 E x pertise
B o och ´93 OMT - 2
O ther m ethods B ooch ´91 OMT - 1 OOSE F ragm entation
Los socios del UML contribuyeron con su perspectiva tecnológica, con la Modelación de
negocios, con un lenguaje reservado (OCL), con semántica para una máquina de
estados, con tipos, interfaces, componentes, colaboraciones y con un metamodelo. Cada
socio proporciono su propia perspectiva del área donde trabajaba y el resultado
beneficio a todos ellos.
2.4 Ventajas de UML

UML es un método que puede utilizar todo el mundo. Muchas metodologías,
organizaciones y herramientas lo utilizan. Hay dos características por las que se debe
utilizar el UML:
x Eliminó las diferencias, que producen inconsistencia, entre los lenguajes de modelado
de métodos antiguos.
x Unificó la perspectiva de muchos tipos diferentes de sistemas (negocio vs. software),
conceptos de desarrollo (requerimientos de análisis, diseño e implementación) y
conceptos internos.
UML se podría utilizar como un lenguaje de modelado para aprender métodos orientados
al objeto.
UML se ha convertido de facto en el lenguaje de modelado orientado a objetos estándar.
Las razones que han llevado a tal punto son:
Participación de expertos en metodologías influyentes.
Participación de importantes empresas.

£
Aceptación del OMG como notación estándar.
2.5 Inconvenientes de UML

Entre los inconvenientes que podrían identificarse están:
Existe la tenatción de utilizar UML para definir el proceso de desarrollo, pero UML no es
una metodología
Falta integración con respecto de otras técnicas tales como patrones de diseño,
interfaces de usuario, documentación, etc.
Se ha producido un "monopolio” de conceptos, técnicas y métodos en torno a UML.
2.6 Elementos de UML

Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y para
esto se requiere aprender sus tres elementos principales:
1. Los bloques básicos de construcción de UML.
2. Las reglas que dictan cómo se pueden combinar estos bloques
básicos.
3. Algunos mecanismos comunes que se aplican a través de UML.
2.6.1 Bloques de construcción de UML

UML tiene tres clases de bloques de construcción:
1. Elementos.
2. Relaciones.
3. Diagramas.
Los elementos son abstracciones que son cuidados de primera clase en un modelo, las
relaciones ligan estos elementos entre sí; y los diagramas agrupan colecciones interesantes
de elementos
2.6.1.1 Elementos de Modelado
2.6.1.1.1 Elementos Estructurales

Son los nombres de los modelos, son parte estática de un modelo y representan elementos
conceptuales:
1. CLASE
Una clase es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica; implementa una o más interfaces.
Ventana
Origen
Tamaño
Abrir()
Cerrar()
Mover()
Dibujar()

£
2. INTERFAZ
Una interfaz es una colección de operaciones que especifican un servicio de una clase
o componente, esta describe el comportamiento visible externamente de ese
elemento, puede representar el comportamiento completo de una clase o
componente.
Una interfaz define un conjunto de especificaciones de operaciones, pero nunca un
conjunto de implementaciones de operaciones
3. COLABORACIÓN
Una colaboración define una interacción y es una sociedad de roles y otros elementos
que colaboran para proporcionar un comportamiento cooperativo mayor que la suma
de los comportamiento de sus elementos, tienen dimensión tanto estructural como de
comportamiento, estas representan la implementación de patrones que forman un
sistema
Una clase puede participar en varias colaboraciones,
Cadena de
responsabilidad
4. CASO DE USO
Un caso de uso es una descripción de un conjunto de secuencias de acciones que
produce un resultado observable de interés para un actor en particular, es estructurar
los aspectos de comportamiento de un modelo.
Es realizado por una colaboración.
Realizar Pedido
5. CLASE ACTIVA
Una clase activa es una clase cuyos objetos tienen uno o más procesos o hilos de
ejecución y por lo tanto pueden dar origen a actividades de control, presentan
elementos cuyo comportamiento es concurrente con otros.
GestorEventos
Suspender()
VaciarCola()
6. COMPONENTE
Un componente es una parte física y reemplazable de un sistema que conforma con
un conjunto de interfaces y proporciona la implementación de dicho conjunto.
Representa típicamente el empaquetamiento físico de diferentes elementos lógicos,
como clases, interfaces y colaboraciones.

£
Orderform.jav
7. NODO
Un Nodo es un elemento físico que existe en tiempo de ejecución y representa un
recurso computacional que por lo general dispone de algo de memoria y con
frecuencia, capa con capacidad de procesamiento.
servidor
Los siete elementos anteriores son los elementos estructurales básicos que se puede incluir en
un modelo UML.
También existen variaciones de estos siete elementos, tales como actores, señales, utilidades,
procesos e hilos, y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas
2.6.1.1.2 Elementos de Comportamiento

Son las partes dinámicas de los modelos, son los verbos y representan comportamiento en
el tiempo y el espacio. Hay dos tipos principales de elementos de comportamiento:
1. INTERACCIÓN
Una interacción es un comportamiento que comprende un conjunto de mensajes
intercambiados entre un conjunto de objetos, dentro de un contexto particular, para
alcanzar un propósito específico. Una interacción, involucra muchos otros elementos,
incluyendo mensajes, secuencias de acción, y enlaces.
Dibujar
Mensajes
2. MÁQUINA DE ESTADOS
Una máquina de estados es un comportamiento que especifica las secuencias de
estados por las que pasa un objeto o una interacción durante su vida en respuesta a
eventos, junto con sus reacciones a estos eventos.
El comportamiento de una clase individual o una colaboración de clases pueden
especificarse con una máquina de estado, e involucra a otros elementos, incluyendo
estados, transiciones, eventos, y actividades:
Esperando Estados
2.6.1.1.3 Elementos de Agrupación

£
Son las partes organizativas de los modelos, son cajas en las que puede descomponerse
un modelo. Un paquete es un mecanismo de propósito general para organizar elementos
en los grupos. Los elementos estructurales, los elementos de comportamiento e incluso
otros elementos de agrupación pueden incluirse en un paquete., también es puramente
conceptual.
R e g la s d e l n e g o c io
2.6.1.1.4 Elementos de Anotación

Son las partes explicativas de los modelos., pueden aplicar para describir, clarificar y hacer
observaciones sobre cualquier elemento de un modelo, la Nota es simplemente un
símbolo para mostrar las restricciones y comentarios junto a un elemento o una colección
de elementos.
D e v u e lv e u n a c o p ia d e l
o b jeto re ce p to r
N o ta
2.6.1.2 Relaciones
Hay cuatro tipos de relaciones:
1. DEPENDENCIA
Es una relación semántica entre dos elementos, en la cual un cambio a un elemento
independiente puede afectar a la semántica del otro elemento dependiente
Depéndencias
2. ASOCIACIÓN
Es una relación estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregación es un tipo especial de asociación, en que
representa una relación estructural entre un todo y sus partes
0....1 *
patrón empleado
3. GENERALIZACIÓN
Es una relación de especialización / generalización en la cual los objetos del elemento
especializado (hijo) pueden sustituir a los objetos del elemento general (padre). De
esta forma, el hijo comparte la estructura y el comportamiento del padre.
Generalizaciones

£
4. REALIZACIÓN
Es una relación semántica entre clasificadores, en donde un clasificador especifica un
contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones
de realización en dos sitios: entre interfaces y las clases y componentes que las realizan,
entre los casos de uso y las colaboraciones que los realizan.
R ealización
Estos cuatro elementos son los básicos relacionales. Existes variaciones son como el
refinamiento, la traza, la inclusión y la extensión.
2.6.1.3 Diagramas UML

Un modelo representa a un sistema software desde una perspectiva específica. Al igual
que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura
vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del
sistema.
Los modelos de UML que se tratan a continuación son los siguientes:
1. Diagrama de Estructura Estática.
2. Diagrama de Casos de Uso.
3. Diagrama de Secuencia.
4. Diagrama de Colaboración.
5. Diagrama de Estados.
2.6.1.3.1 Elementos Comunes a Todos los Diagramas

NOTAS
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento
de un diagrama. Es un modo de indicar información en un formato libre, cuando la
notación del diagrama en cuestión no nos permite expresar dicha información de manera
adecuada.
Una nota se representa como un rectángulo con una esquina doblada con texto en su
interior, y puede aparecer en un diagrama, sola o unida a un elemento por medio de una
línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un
procedimiento, etc.
2.6.1.3.2 Diagramas de Estructura Estática (Diagrama de clases)

Con el nombre de Diagramas de Estructura Estática (Diagrama de clases) se engloban los
siguientes elementos:
Modelo Conceptual de la fase de Análisis - modela elementos del dominio.
Diagrama de Clases de la fase de Diseño - presenta los elementos de la solución
software (con detalles de implementación).
Comparten la notación para los elementos que los forman (clases y objetos) y las
relaciones que existen entre ellos (asociaciones).
El diagrama de clases es el diagrama principal para el análisis y diseño. Presenta las clases
y objetos del sistema con sus relaciones estructurales y de herencia, así como la definición

£
de atributos y operaciones de la clase. A seguir, vemos un ejemplo de diagrama de clase

de análisis:
Cliente Factura
Corresponde
Nombre: texto Concepto: texto
1 *
Dirección: texto Cantidad: número
Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se
muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones.
Termómetro Nombre de la clase
temperaturaDeseada Atributos de clase

temperaturaMedida
establecerTemp() Operaciones o métodos
Una clase puede representarse de forma esquemática (plegada), con los detalles como
atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre
de la clase.
Objetos
Un objeto se representa de la misma forma que una clase. En el compartimiento superior
aparece el nombre del objeto junto con el nombre de la clase, ambos subrayados, según
la siguiente sintaxis:
nombre_del_objeto: nombre_de_la_clase
Asociaciones
Las asociaciones entre dos clases se representan mediante una línea que las une.
La línea puede tener una serie de elementos gráficos que expresan características
particulares de la asociación.
A continuación se verán los más importantes de entre dichos elementos gráficos.
Agregación
La agregación es un tipo de relación jerárquica entre un objeto que representa la
totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento físico
de estructuras relacionadas lógicamente. Los objetos "son-parte-de" otro objeto
completo. Por ejemplo, motor, ruedas, carrocería son parte de coche.
Se representa con un rombo hueco en la clase cuya instancia es una agregación de
las instancias de la otra.

£
Coche
Ruedas Motor Carrocería
Asociación
Las relaciones de asociación representan un conjunto de enlaces entre objetos o
instancias de clases. Es el tipo de relación más general y denota básicamente una
dependencia semántica. Por ejemplo, una Persona trabaja para una Empresa.
Se representa como una línea continua entre las clases asociadas. Ambos extremos de
la línea pueden conectar con la misma clase, indicando que una instancia de una
clase, está asociada a otras instancias de la misma clase, lo que se conoce como
asociación reflexiva.
La relación puede tener un nombre y un estereotipo, que se colocan junto a la línea. El
nombre suele corresponderse con expresiones verbales presentes en las
especificaciones, y define la semántica de la asociación. Los estereotipos permiten
clasificar las relaciones en familias y se escribirán entre el símbolo: << ... >>.
Cada asociación puede presentar elementos adicionales que doten de mayor detalle
al tipo de relación:
{ Multiplicidad - Describe la cardinalidad de la relación, es decir, especifica cuántas
instancias de una clase están asociadas a una instancia de la otra clase. Los tipos
de multiplicidad son:
Rep. simbólica Significado
1..1 Uno a uno
1..* Uno a muchos
*..* Muchos a muchos
{ Orden: Se puede especificar si las instancias guardan un orden con la palabra

clave ‘{ordered}’. Si el modelo es suficientemente detallado, se puede incluir una
restricción que indique el criterio de ordenación.
{ Navegabilidad - La navegación desde una clase a la otra se representa poniendo
una flecha sin relleno en el extremo de la línea, indicando el sentido de la
navegación.
{ Rol o nombre de la asociación - Este nombre se coloca junto al extremo de la línea
que esta unida a una clase, para expresar cómo esa clase hace uso de la otra
clase con la que mantiene la asociación. Describe la semántica de la relación en
el sentido indicado. Por ejemplo, la asociación entre Persona y Empresa recibe el
nombre de trabaja para, como rol en ese sentido.
Herencia
Las jerarquías de generalización/especialización se conocen como herencia. Herencia
es el mecanismo que permite a una clase de objetos incorporar atributos y métodos de
otra clase, añadiéndolos a los que ya posee. Con la herencia se refleja una relación

£
"es_un" entre clases. La clase de la cual se hereda se denomina superclase, y la que

hereda subclase.
La generalización define una superclase a partir de otras. Por ejemplo, de las clases
profesor y estudiante se obtiene la superclase persona. La especialización o
especificación es la operación inversa, y en ella una clase se descompone en una o
varias subclases.
Persona
Alumno Profesor
2.6.1.3.3 Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa.
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos
de uso y relaciones entre casos de uso.
Actores
Un actor es algo o alguien que se encuentra fuera del sistema y que interactúa con él. En
general, los actores serán los usuarios del sistema y los sistemas externos al que se esté
desarrollando. Si se habla de usuarios, un actor es el papel que puede llevar a cabo en
cuanto a su forma de interactuar con el sistema, es decir, un único actor puede
representar a muchos usuarios diferentes y de la misma forma, un usuario puede actuar
como actores diferentes.
Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen
entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea
específica. Representa el comportamiento del sistema de información desde el punto de
vista del usuario. Típicamente será un conjunto de transacciones ejecutadas entre el
sistema y los actores.
Un caso de uso se representa mediante una elipse con el nombre del caso de uso dentro o
debajo. El nombre del caso de uso debe reflejar la tarea específica que el actor desea
llevar a cabo usando el sistema y debería tener un verbo para enfatizar que se trata de un
proceso, por ejemplo: Comprar Artículos o Realizar Pedido.
Para facilitar la comprensión de los casos de uso del sistema de información en el análisis,
es posible agruparlos en paquetes según funcionalidades semejantes o relacionadas.
Un paquete se representa con un icono con forma de carpeta y con el nombre colocado
en la 'pestaña'. Los paquetes también pueden formar diagramas que complementen al
diagrama de casos de uso.
Relaciones
Relación entre un actor y un caso de uso.

£
Es una relación de comunicación, que indica que un actor interviene en el caso de uso.
Normalmente, el actor aporta información para la realización de un caso de uso o recibe
información como resultado de la realización del mismo, por ello, esta relación puede ser
unidireccional o bidireccional, aunque generalmente se muestra como bidireccional, ya
que no es necesario especificar en detalle estas relaciones.
Las relaciones entre un actor y un caso de uso se representan mediante una línea continua
entre ellos.
Relación entre casos de uso.
La relación entre casos de uso es una relación unidireccional. Esta relación puede
presentar uno de los dos siguientes tipos: usa y extiende.
o La relación usa - Cuando un caso de uso utiliza a otro.
o La relación extiende - Cuando un caso de uso especializa a otro extendiendo su
funcionalidad.
2.6.1.3.4 Diagramas de Interacción

Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las
aplicaciones.
Los diagramas de interacción muestran cómo se comunican los objetos en una
interacción
Hay dos tipos de diagramas de interacción basados en la misma información, pero cada
uno enfatizando un aspecto particular:
2.6.1.3.4.1 Diagrama de Secuencia

Los Diagramas de Secuencia son más adecuados para observar la perspectiva
cronológica de las interacciones. En particular, muestra los objetos participantes en la
interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo.
El eje vertical representa el tiempo (que fluye de arriba abajo), y en el eje horizontal se
colocan los objetos y actores participantes en la interacción, sin un orden prefijado.
Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos.

£
Cuando el envío es síncrono el retorno se considera implícito y no es necesario indicar el

retorno del control (figura superior), pero en caso de retorno asíncrono, si existe retorno, se
debe representar:
2.6.1.3.4.2 Diagrama de Colaboración

Normalmente el Diagrama de Colaboración se obtiene a partir del correspondiente D. de
Secuencia.
A diferencia con el diagrama de secuencia, el diagrama de colaboración muestra los
enlaces de comunicación entre objetos, no la secuencia en el tiempo en que se producen
los mensajes.
Un diagrama de colaboración lo forman objetos, enlaces y mensajes.
Un objeto es una instancia de una clase que participa como una interacción.
Un enlace es una instancia de una asociación que conecta dos objetos de un
diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento

£
consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir
un intercambio de mensajes entre los objetos conectados.
Mensajes - Los diagramas de interacción indican el flujo de mensajes entre elementos
del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a
otro si entre ellos existe un enlace. Cada mensaje lleva un número de secuencia.
2.6.1.3.5 Diagrama de Estados

Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso
o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado
a otro y cuáles son las respuestas y acciones que genera.
Cada objeto está en un estado en cierto instante. El estado está caracterizado
parcialmente por los valores de los atributos del objeto. El estado en el que se encuentra
un objeto determina su comportamiento.
En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son
estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los
eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su
interior. Una transición se representa como una flecha desde el estado origen al estado
destino.
Contratar
En paro En activo
Perder empleo
Jubilarse Jubilarse
Jubilado
El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido
rodeado de otro círculo. En realidad, los estados inicial y final son pseudo-estados, pues un
objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles es la transición
inicial y final(es).
2.6.2 Mecanismos comunes de UML

Hay cuatro mecanismos que se aplican de forma consistente a través de todo el lenguaje
Especificaciones
Las especificaciones proporcionan una explicación textual de la semántica de ese
bloque de construcción. Se utilizan para visualizar un sistema, y también para detallar el
sistema.
Las especificaciones en UML proporcionan una base semántica que incluye a todos
los elementos de todos los modelos de un sistema, y cada elemento está relacionado
con otros de manera consistente.
Los diagramas de UML son así simples proyecciones visuales de esa base y cada
diagrama revela un aspecto específico interesante del sistema.

£
Adornos
La notación de la clase también revela los aspectos más importantes de una clase a
saber: su nombre, atributos y operaciones.
La especificación de una clase puede incluir otros detalles, tales como si es abstracta o
la visibilidad de sus atributos y operaciones. Muchos de estos detalles se pueden incluir
como adornos gráficos o textuales en la notación rectangular básica de la clase.
Transacción
+ Ejecutar()
+ Rollback()
# prioridad()
Divisiones comunes
La primer división entre clase y objeto, una clase es una abstracción; un objeto es una
manifestación concreta de esa abstracción;
Arquitectura
Ciente
Nombre J u a n :C lie n te
Dirección
teléfono :C lie n te
Elisa
La segunda división la tenemos entre interfaz e implementación. Una interfaz declara

un contrato, y una implementación representa una realización concreta de ese
contrato, responsable de hacer efectiva la forma fidedigna la semántica completa de
la interfaz
A sisten teortog .dll
Mecanismos de Extensibilidad.
x Estereotipos

£
x Valores etiquetados
x Restricciones
Estereotipo, extiende el vocabulario de UML, permitiendo crear nuevos tipos de
bloques de construcción que deriven de los existentes pero sean específicos a un
problema
ColaEventos
“exception” (versión =3.2

Overflow autor = egb)
Añadir() {ordenado}
Quitar()
Vaciar()
Valor etiquetado extiende las propiedades de un bloque de construcción de UML,

permitiendo añadir nueva información en la especificación de ese elemento.
Restricción extiende la semántica de un bloque de construcción de UML, permitiendo
añadir nuevas reglas o modificar las existentes.
3.- El modelo CORBA

CORBA son las siglas de Common Object Request Broker Architecture, o arquitectura
común de mediador de peticiones de objetos.
3.1 Introducción
Las redes como Internet, o las redes corporativas son una mezcla de tecnologías, en las
que podemos encontrar estaciones de trabajo, mainframes, ordenadores con diferentes
sistemas operativos que van sobre una simple red de cable coaxial o una gran red ATM
con poderosas fibras ópticas y como si fuera poco trabajando con diferentes protocolos,
podemos decir entonces, que dichas redes son heterogéneas y pueden convertirse en un
problema a la hora de hacer que aplicaciones existentes, interactúen con nuevas
aplicaciones que trabajan en entornos tecnológicos de vanguardia o incluso ya existentes,
lo que hace imposible que sistemas antiguos, sean reemplazados sin tener en cuenta una
relación costo beneficio.
De cara al problema antes mencionado, la OMG (Object Management Group) fue
formada en 1989 y actualmente esta conformada por más de 700 compañías, con el
ánimo de adoptar y promover estándares para el desarrollo de aplicaciones en entornos
distribuidos heterogéneos, siendo una función de los miembros de la OMG aportar ideas y
contribuir con su tecnología a los RFPs (Request For Proposal) lanzados por la OMG, gracias
a las respuestas a estos RFPs, la OMG adopta estándares basados en tecnologías de
objetos existentes en el mercado.
Por otra parte, el auge de la descentralización de los sistemas, de los servicios que brindan
los mismos a terceros y en especial de las personas, los entornos distribuidos son en buena
forma una gran opción en el desarrollo de sistemas compactos y versátiles que de cara a
la tecnología dan solución a muchos problemas de diferente índole y en diferentes

£
campos, como la medicina, las telecomunicaciones, la banca, la manufactura, la tele-

ingeniería y el tele-trabajo entre otros. Existen muchos proyectos de investigación que
utilizan uno de los componentes más importantes de la arquitectura de administración de
objetos OMA (Object Management Architecture) de la OMG llamado CORBA para dar el
soporte distribuido a sus aplicaciones en desarrollo, este es el caso de los proyectos MATES
("Multimedia Assisted Tele-Engineering Service) y VITAL (Validation of Integrated
Telecommunication Architectures for the Long term , proyectos de ámbito europeo
financiados por la comunidad europea; en una parte del proyecto MATES, se utiliza
CORBA como soporte de desarrollo de una herramienta de gestión de configuración, que
permite a desarrolladores geográficamente dispersos, desarrollar software en conjunto; en
el proyecto VITAL se utiliza CORBA como DPE (Distributed Processing Environment) para el
desarrollo de un prototipo que implemente la Arquitectura de Servicios y la de
Configuración de Recursos basadas en redes de banda ancha (ATM) de TINA (
Telecommunications Information Networking Architecture).
3.2 La Arquitectura de Administración de Objetos (OMA)

OMA (Object Management Architecture) pretende definir en un alto nivel de abstracción
las reglas necesarias para la distribución de la computación orientada a objetos (OO) en
entornos heterogéneos. OMA se compone de dos modelos, el Modelo de Objetos y el
Modelo de Referencia, el primer modelo define como se deben describir los objetos
distribuidos en un entorno heterogéneo y el segundo modelo caracteriza las interacciones
entre dichos objetos.
En el modelo de Objetos de OMA, un Objeto es un ente encapsulado con una única

identidad y por intermedio de una interfaz bien definida es posible acceder a sus servicios
(cuando un cliente solicita los servicios de un objeto, la localización y la implementación
de dicho objeto son transparentes al cliente û El cliente no necesita saberlo, simplemente
solicita el servicio a través de la interfaz antes mencionada).

£
Los componentes del Modelo de Referencia de OMA lo podemos apreciar en la figura 1,

su núcleo es el ORB ("Object Request Broker"- mediador de peticiones de objeto), además
de dar transparencia en la localización y activación de objetos, se encarga de facilitar la
comunicación entre clientes y dichos objetos. Vamos ahora a describir el conjunto de
interfaces que utilizan el ORB en el modelo de referencia en cuestión.
3.2.1 Servicios de objeto

Es un a colección de interfaces de dominio independiente, que aumentan y
complementan la funcionalidad del ORB, estas interfaces son usadas por muchos
programas que distribuyen sus objetos ("Distributed Object Programs"), por ejemplo,
servicios que descubren otros servicios disponibles en el dominio de las aplicaciones, entre
ellos están:
El Servicio de Nombres: Permite a un cliente encontrar un objeto por su nombre.
El Servicio de "Traiding": Permite a un cliente encontrar objetos basándose en sus
propiedades.
Sin embargo existen otros tipos de servicios como el servicio de persistencia (permite a un
cliente almacenar objetos persistentemente), servicio de ciclo de vida (define operaciones
para crear, copiar, mover y borrar objetos de un ORB), servicio de seguridad (da entre
muchas más, soporte de autenticaciones, listas de control de acceso a objetos), servicio
de eventos (permite a los objetos dinámicamente registrarse ante el interés de un
particular evento) y muchos más como el servicio de transacciones, de control de
concurrencia, de búsqueda y de inicialización entre otros.
3.2.2 Facilidades comunes

Al igual que las interfaces de servicios de objetos, estas interfaces son de orientación
horizontal (Es decir que pueden ser usadas en cualquier campo, por ejemplo en medicina,
telecomunicaciones, tele-ingeniería, etc.) y están orientadas a aplicaciones de usuario
final, como un ejemplo el Distribute Document Component Facility (DDCF) de OMG,
basado en OpenDoc de Apple Computer, que permite la composición, presentación e
intercambio de objetos basados en un modelo de documento, facilitando por ejemplo, la
incorporación de un objeto hoja de calculo en un documento maestro de reportes (que es
igualmente un objeto). Es posible entonces, que en un entorno de trabajo de personas
geográficamente distribuidas, exista una aplicación que utilice el DDCF para la
generación e intercambio de documentos. Las Facilidades comunes están en desarrollo
permanente, entre ellas están, facilidades comunes para agentes móviles, intercambio de
datos e internacionalización entre otras.
3.2.3 Interfaces de Dominio

Estas interfaces al igual que las mencionadas anteriormente cumplen roles similares,
excepto que las interfaces mencionadas en el presente contexto están orientadas a
aplicaciones de dominio específico, por ejemplo, interfaces destinadas a aplicaciones
financieras, o a aplicaciones de telecomunicaciones o de manufactura (como es el caso
de uno de los primeros RFPs de OMG para la administración de datos de producto), es por
ello que en la figura 1 existen diferentes gráficas de dominios de interfaces, que representa
un campo o un dominio de aplicaciones (en telecomunicación, medicina, etc.).
3.2.4 Interfaces de Aplicación

Aquí convergen las interfaces desarrolladas para una aplicación especifica, estas
interfaces no están estandarizadas, primero por que ellas son aplicaciones especificas y

£
segundo por que OMG no desarrolla, solo específica, sin embargo, existe la posibilidad de
que dichas interfaces sean candidatas a un estándar de OMG, si es que con el tiempo,
algunos servicios emergen de dicha aplicación de dominio específico.
Para finalizar está breve introducción a OMA, cabe mencionar que existe un concepto
llamado el "Object Framework" o marco de objetos, ver la figura 2, la figura representa un
conjunto de objetos que interactuan entre sí, formando una aplicación que soluciona un
problema en un dominio especifico, por ejemplo en las telecomunicaciones, la banca, la
manufactura o la medicina y que cada uno de los círculos en la figura, representan
componentes que se comunican entre sí a través de un ORB, los cuales soportan todas o
algunas de las interfaces descritas en el Modelo de Referencia (Interfaces de aplicación,
Interfaces de dominio especifico, Facilidades comunes y/o interfaces de servicios de
objeto) antes mencionado; estos componente se comunican entre sí (en forma "peer-to-
peer"), comportándose unas veces como cliente y otras como servidor.
Por otra parte, en la figura 2 apreciamos como el componente (Cliente) que soporta todas
las interfaces, hace requerimientos a un componente (Servidor) que soporta solamente
interfaces SO, también, como otro componente cliente que soporta interfaces FC y SO,
hace requerimientos a un componente servidor con interfaces SO. En la figura 2, vemos
que existe un requerimiento marcado como "Call-Back", este caso se presenta cuando un
componente que se comporta como un servidor, hace peticiones a un cliente, haciendo
que dicho cliente pueda comportarse como cliente y servidor al mismo tiempo, (Un
ejemplo demostrativo con estas características esta incluido en la guía del programador
de OrbixWeb de IONA).
3.3 EL Mediador de Peticiones de Objeto (ORB)

CORBA es una infraestructura computacional abierta de objetos distribuidos, que esta
siendo especificada por la OMG (Grupo de Gestión de Objetos), con el ánimo de describir
todas las características del ORB de OMA. En la figura 3 podemos apreciar cada uno de
los componentes de CORBA, y a continuación describiremos cada uno de ellos.

£
3.3.1 El cliente
Es la entidad que invoca operaciones sobre un objeto de la implementación de objetos,
Los servicios que brinda dicho objeto son transparentes al llamante, bastaría simplemente
con invocar un método sobre un objeto; de tal forma que un objeto remoto para una
entidad cliente (local y llamante) se comporta como si fuese un objeto local (ver flechas
punteadas de la figura 3).
3.3.2 ORB (Object Request Broker)

El ORB es el encargado de dar transparencia en la comunicación a los clientes, en lo que
se refiere al envío de requerimientos y al retorno de respuestas, cuando dichos clientes,
solicitan los servicios de un objeto. El objeto que un cliente desea y al que el ORB envía sus
requerimientos, es llamado el target object. Mucha de la transparencia a la que antes nos
referíamos sé reflejada en que comúnmente el ORB se encarga de la localización de los
objetos ya que le cliente no la conoce, ni la necesita (un objeto puede estar en un
proceso corriendo en otra maquina dentro de la red o sobre la misma maquina, corriendo
en diferente o el mismo proceso), el cliente tampoco conoce la implementación de los
objetos con los que desea interactuar, ni el lenguaje de programación en que están
escritos, ni el sistema operativo, ni el "hardware" sobre el cual están corriendo; el cliente
tampoco se preocupa de la activación de los objetos requeridos, ya que el ORB es el
encargado de activar los objetos si fuese necesario, además, el cliente no necesitará
conocer los mecanismos de comunicación (TCP/IP, llamada de métodos locales, etc.) que
sé utilizan, simplemente el ORB pasa los requerimientos de los clientes a los objetos y envía
una respuesta a quien hizo el requerimiento; por otra parte, la transparencia del ORB
permite que los desarrolladores se preocupen más de sus aplicaciones y menos de los
asuntos que tengan que ver con programación de sistemas distribuidos a bajo nivel.
3.3.3 Interfaz ORB

Es un conjunto de librerías o APIs (Access Point Interfaces) que definen un conjunto de
funciones del ORB y que pueden ser accedidas directamente por el código cliente, entre
ellas están las de convertir las referencias de objetos (cuando se solicita un servicio a un
target object el servidor envía una referencia de dicho objeto, que en realidad es la

£
información necesaria que un cliente necesita para interoperar con el ORB y dicho target
object) en strings o vise versa y las que sirven para crear listas de argumentos de
requerimientos, hechos a través de una invocación dinámica, vista un poco más adelante.
3.3.4 Lenguaje de Definición de Interfaces (IDL)

Cuando un cliente solicita los servicios de un objeto, este debe conocer las operaciones
soportadas por dicho objeto, las interfaces de un objeto simplemente describen dichas
operaciones. OMG IDL (Interface Definition Language) es un lenguaje de "especificación"
parecido en estructura a C++, que permite declarar el "contacto" de un objeto con el
mundo exterior. Una de las ventajas de describir interfaces de esta forma, es separar los
puntos de acceso a un objeto (Sus interfaces) de su propia implementación, lo que
permite que los objetos sean implementados en diferentes lenguajes de programación (C,
C++, Java, Ada 95, SmallTalk, Cobol) e interactúen entre sí en forma transparente (aspecto
importante en un sistema heterogéneo), ver la siguiente figura.
3.3.5 IDL Stubs e IDL Skeletons

Un Stub (normalmente llamado Proxy) es un ente encargado de enviar los requerimientos
de un cliente a un servidor a través del ORB (comúnmente llamado marshaling, que
consiste en convertir los requerimientos de un cliente implementado en un algún lenguaje
de programación en una representación adecuada para el envío de información a través
del ORB); el Skeleton (en el servidor) es el encargado de colaborar con la recepción de
dichos requerimientos desde el ORB y enviarlos a la Implementación de Objetos de CORBA
( Comúnmente llamado unmarshaling, que es simplemente hacer una conversión de un
formato de transmisión a un formato en un lenguaje de programación dado), visto de
atrás hacia delante, a través del Skeleton se envía alguna respuesta a través del ORB y es
recibida por el cliente por intermedio del Stub, normalmente al conjunto de los envíos a
través del Stub y el Skeleton es llamado invocación estática (tanto el cliente como el
objeto de implementación, tienen pleno conocimiento de las interfaces IDL que están
siendo invocadas).
3.3.6 Repositorio de Interfaces (IR)

El IR (Interface Repository) es una base de datos distribuida que contiene información de
las interfaces IDL definidas para los objetos que cooperarán en un entorno distribuido y
que puede ser accedida o sobre escrita en tiempo de ejecución; podemos pensar en el IR

£
como un Objeto CORBA, con una base de datos asociada y que tiene un conjunto de
operaciones que pueden ser utilizadas como si fuese un objeto cualquiera, entre los
servicios que ofrece dicho Objeto CORBA, es permitir navegar sobre la jerarquía de
interfaces almacenadas en la base e datos, de tal forma que se pudiese saber si se
quisiere, la descripción de todas las operaciones que un objeto soporta Una forma muy
interesante y de mucha utilidad es usar el IR para descubrir interfaces de objetos en tiempo
de ejecución, empleando invocación dinámica, que se verá a continuación.
3.3.7 DDI y DSI

El otro tipo de invocación que existe en CORBA es la Invocación Dinámica, que permite en
tiempo de ejecución (run-time), descubrir las operaciones de un objeto, sin tener un
conocimiento previo de sus interfaces (sin un stub), para dicha invocación dinámica
existen dos tipos de interfaces, una es la Interfaz de Invocación Dinámica DII (Dinamic
Invocation Interface) y la otra es llamada el DSI (Dinamic Skeleton Interface), el DII en una
aplicación cliente que se encarga de hacer peticiones de algún objeto del que no se
conocen sus interfaces, dicha petición se hace a través de un pseudo objeto llamado
request, sobre el cual el cliente especifica el nombre de la operación y sus argumentos
que pueden ser obtenidos del Repositorio de Interfaces(IR). Cuando el request este
completo se le envía al servidor, dicho envío puede hacerse de tres formas, en la primera
el request se envía y todos los procesos se bloquean hasta que el servidor emita una
respuesta (Invocación Sincrónica), en la segunda cuando el request se envía, el cliente
sigue procesando y más tarde recoge la respuesta (Invocación Sincrónica Aplazada), en
la última forma cuando se envía el request, el cliente sigue procesando y la respuesta del
servidor se recoge por algún otro medio (por ejemplo un proceso separado que la recoja).
En el lado del servidor, cuando un request (pseudo objeto) es recibido, el DSI es quien lo
toma y envía alguna respuesta al cliente ante la petición solicitada (lo que es llamado el
Dispatching). En la figura 5 se puede apreciar de una manera gráfica una forma de hacer
invocación dinámica.
3.3.8 Adaptador de Objetos

Es el ente de contacto entre el ORB y los objetos de implementación y es quien acepta
requerimientos en nombre de los objetos servidores, dicho adaptador se encarga en

£
tiempo de ejecución de activar, instanciar, pasar requerimientos y generar referencias de

dichos objetos. También, de colaborar con el ORB para que todos los requerimientos que
se hagan de múltiples conexiones, sean recibidos sin ningún tipo de bloqueo. El adaptador
de objetos tiene tres interfaces asociadas, una al DSI, una al IDL skeleton y otra a la
implementación de objetos (Ver figura 3) siendo las dos primeras privadas y la ultima
publica, todo esto con él animo de aislar la implementación de los objetos del ORB tanto
como sea posible.
La OMG estandarizo un adaptador de objetos llamado BOA (Basic Object Adaptator),
dicho BOA y los servidores, tiene la posibilidad de soportar más de un adaptador de
objetos. OMG actualmente ha lanzado una especificación que mejora algunos defectos
de portabilidad del adaptador de objetos BOA y es llamada POA (Portable Object
Adaptator).
3.3.9 Repositorio de Implementación

Es una base de datos que en tiempo de ejecución, da información acerca de las clases
que un servidor soporta, los objetos que están instanciados, sus identificadores IDs (es un
número único que asigna el adaptador de objetos a cada instancia de un objeto) y una
serie de datos administrativo de los objetos, como trazas de información e información de
seguridad entre otros.
3.3.10 Protocolos del ORB

CORBA tiene una arquitectura general de interoperabilidad entre ORBs, una directa ORB a
ORB y otra basada en puentes (Bridge), el primer tipo de interoperabilidad es dada
cuando los ORBs residen en el mismo dominio, compartiendo las mismas referencias de
objeto, el mismo tipo de información IDL y tal vez la misma información de seguridad; el
segundo tipo de interoperabilidad se da cuando se desean comunicar ORBs de diferentes
dominios, entonces el Bridge se encarga de mapear la información especifica de un ORB
a otro, en la figura 6 se puede apreciar esta característica. La arquitectura de
interoperabilidad de ORBs es basada en GIOP (General Inter-ORB Protocol), que especifica
un conjunto de formatos de mensajes y representaciones de datos para la interacción
entre ORBs; GIOP es diseñado para trabajar sobre cualquier protocolo de transporte
orientado a conexión, por ejemplo el protocolo IIOP (Internet Inter-ORB Protocol)
especifica como mensajes GIOP son intercambiados sobre redes TCP/IP, gracias a IIOP, es
posible usar Internet como un Backbone ORB sobre el cual, otros ORBs pueden conectarse.
(Para ser compatible con el ORB de CORBA se debe soportar GIOP sobre TCP/IP).

£
Por otra parte la arquitectura de interoperabilidad entre ORBs, define un conjunto de

protocolos llamados ESIOPs (Environment-specific inter-ORB Protocols) que hacen posible la
interacción de ORBs sobre redes especificas, por ejemplo uno de los primeros ESIOPs
especificados fue el utilizado por el entorno de computación distribuida DCE (Distributed
Computing Environment) llamado DCE-CIOP (DCE Common Inter-ORB Protocol), con él
animo de que el mundo de las aplicaciones CORBA y DCE, interoperen en forma
transparente (Ver figura 6), es importante destacar aquí, que GIOP especifica un formato
para las referencias de los objetos, llamado IOR (Interoperable Object Reference), dicho
IOR almacena información necesaria para localizar y comunicar un objeto sobre uno o
más protocolos, como datos que identifiquen él dominio del ORB sobre el cual una
referencia es asociada y también los protocolos que esta soporta, por ejemplo un IOR que
contiene información de un dominio IIOP almacenara información de un nombre de un
"ost (nombre de una máquina o dirección IP) y un número de puerto TCP/IP.
3.4 Implementaciones de CORBA en el mercado

En el mercado existen compañías que han adoptado a CORBA como opción para el
desarrollo de productos y otras como una buena opción de abrirse paso en el mercado en
diferentes campos, telecomunicaciones, medicina, manufactura, banca, etc. Hay
diferentes compañías que implementan el ORB de OMG entre ellos están el Orbix y
OrbixWeb de IONA (Para aplicaciones C++ y Java respectivamente), NEO y JOE de
SunSoft, HP ORB de HP, SOM de IBM, VisiBroker de Visigenic, ILU de Xerox Parc, Object
Broker de Digital, Netscape´s ONE ORB, Corbus de BBN, Chorus/COOL ORB de Chorus, Dais
de ICL Soft, CorbaPlus de Expersoft, OmniBroker de Object-Oriented Concepts, OmniORB
de Olivette Research Labs y Distribute Smaltalk de ParcPlace entre otros.
3.5 Un Sistema Distribuido con CORBA

En la siguiente figura se puede apreciar un sistema distribuido en tres niveles, el primer nivel
representa a clientes geográficamente dispersos que acceden a los servicios de objetos
residentes en algún servidor en la red; el segundo nivel del sistema, esta formado por un
conjunto de objetos CORBA que efectúan alguna labor para los clientes del anterior nivel,
estos objetos CORBA se pueden servir de otros servidores CORBA residentes en el mismo
nivel o de servidores sistemas independientes, ubicados en el tercer nivel de nuestro

£
sistema, por ejemplo, sistemas de bases de datos o cualquier otro tipo de aplicación. En
cualquier caso, la interacción entre componentes de los niveles, es independiente de la
ubicación de los objetos, del entorno donde residan y del lenguaje en que estén
implementados dichos objetos.
Es importante agregar, que en el cliente pueden residir objetos que interactúan con otros
objetos existentes en la red, como es el caso de objetos encargados de la parte gráfica en
una aplicación, también, el cliente puede acceder a objetos de la red mediante un
browser, como es el caso de applets de java que forman parte de una aplicación
distribuida. Para entender un poco la interacción de los objetos en una aplicación
distribuida, vamos a colocar el caso de una aplicación CORBA implementada en java,
que interactúa con un cliente a través de un browser; en un servidor HTTP existen
documentos html que se encargan de llevar la parte de la aplicación que el cliente
necesita para su interacción con objetos CORBA (a través del browser, ver figura arriba),
cuando lo que el cliente necesita es descargado en su maquina local (por intermedio del
protocolo http), la interacción con los objetos CORBA puede iniciar y se realiza entonces
vía CORBA IIOP; el cliente dada la aplicación en curso, podrá interactuar con objetos de
cualquier servidor CORBA, haciendo uso de un servicio de nombres o de búsqueda, para
la localización de los mismos, quienes a su vez, podrán servirse de aplicaciones residentes
en otro tipo de entornos (lo que permite la integración de aplicaciones existente no
distribuidas a un entorno distribuido).

£

£
Tema III.II.1. Estructura y organización de un departamento de

sistemas de información. Alternativas. Roles y
responsabilidades. Segregación de tareas.
Índice
1.- ORGANIZACIONES ........................................................................................................................... 3
1.1 Concepto de organización...................................................................................................... 3
1.2 Estructura de la organización. ................................................................................................. 3
1.3 Tipos de organizaciones........................................................................................................... 4

1.3.1 Clasificación según su estructura....................................................................................... 4
1.3.1.1 Estructura funcional ....................................................................................................... 4
1.3.1.2 Estructura sectorial ......................................................................................................... 4
1.3.1.3 Estructura mixta .............................................................................................................. 5
1.3.2 Clasificación según su diseño.............................................................................................5
1.3.2.1 Apuntado ........................................................................................................................ 5
1.3.2.2 Plano................................................................................................................................. 5
1.3.2.3 Basado en la línea ......................................................................................................... 5
1.3.2.4 Con orientación a staff .................................................................................................6
1.3.3 Clasificación según el sistema de funcionamiento ........................................................ 6
1.3.3.1 Jerárquico ....................................................................................................................... 6
1.3.3.2 Reticular ........................................................................................................................... 6
1.3.3.3 Formal............................................................................................................................... 6
1.3.3.4 Informal ............................................................................................................................ 6
2.- ESTRUCTURA DE UN DEPARTAMENTO DE SISTEMAS DE INFORMACIÓN......................................... 7
2.1 Áreas del departamento .......................................................................................................... 7

2.1.1 Área de Desarrollo................................................................................................................ 7
2.1.1.1 Análisis .............................................................................................................................. 7
2.1.1.1.1 Análisis funcional ...............................................................................................................................8
2.1.1.1.2 Análisis orgánico................................................................................................................................8
2.1.1.2 Programación ................................................................................................................. 8
2.1.2 Área de Sistemas .................................................................................................................. 9
2.1.3 Área de Producción...........................................................................................................10
2.1.4 Area de redes y comunicaciones ...................................................................................12
2.1.5 Area de atención al usuario .............................................................................................13
2.1.6 Area de administración y servicios ..................................................................................13
2.2 Unidad de seguridad .............................................................................................................. 13
2.3 Unidad de calidad .................................................................................................................. 13
2.4 Organización de reuniones.................................................................................................... 14
3.- ROLES Y RESPONSABILIDADES. SEGREGACIÓN DE TAREAS ......................................................... 16
Temario Oposiciones TIC 1 Tema III.II.01

£
3.1 Director de Tecnologías de Información .............................................................................. 16

3.1.1 Funciones .............................................................................................................................16
3.1.2 Competencias ....................................................................................................................16
3.2 Analista..................................................................................................................................... 17
3.2.1 Funciones .............................................................................................................................17
3.2.2 Competencias ....................................................................................................................17
3.3 Programador............................................................................................................................ 17
3.3.1 Funciones .............................................................................................................................17
3.3.2 Competencias ....................................................................................................................18
3.4 Operador.................................................................................................................................. 18
3.4.1 Funciones .............................................................................................................................18
3.5 Administrador de Base de Datos ........................................................................................... 18

3.5.1 Funciones .............................................................................................................................18

£
1.- Organizaciones
La organización de un centro de sistemas de información está condicionada por el tipo de
organización en el que se encuentra inmersa. Los centros de proceso de datos de la
Administraciones Públicas se encuentran en el contexto de una organización burocrática
que condiciona totalmente su organización y sus formas de trabajo.
1.1 Concepto de organización

La organización de un conjunto de recursos (humanos, materiales, intelectuales, etc.)
supone lo siguiente:
1. Establecer una división del trabajo determinando:
a. Los diferentes tipos de trabajo
b. Las actividades y tareas a desarrollar
c. La definición de puestos
2. Agrupar los puestos homogéneos en departamentos
3. Establecer la delegación de autoridad mediante la fijación de la cadena
jerárquica y la esfera de control, así como la centralización y descentralización de
tareas.
4. Establecimiento de la línea (las unidades productivas o de gestión directa) y el staff
(las unidades de apoyo a las unidades de línea).
1.2 Estructura de la organización.

Para construir la organización en cada caso concreto se deberá realizar la lista de las
actividades y situarlas dentro de este esquema identificando las áreas funcionales.
En una organización por funciones la estructura de la función informática se compone de:
o Sección de análisis y programación, que desarrolla las aplicaciones.
o Sección de explotación y mantenimiento, que planifica y controla el
funcionamiento de equipos y aplicaciones, ejecución de trabajos y recogida de
datos.
o Sección de administración y servicios, que controla el personal, presupuestos,
compras, etc.
En una organización por proyectos, se separan los recursos humanos y materiales por
proyectos, cada uno de ellos dirigido a un área concreta. Un jefe de proyecto coordina
los recursos asignados a ese proyecto.
Otras organizaciones mezclan las dos anteriores, construyendo una organización por
proyectos sobre una organización funcional.
La experiencia de las grandes organizaciones recopilada por consultoras como el Gartner
Group ha puesto de manifiesto la conveniencia de organizar por función y no por
tecnología. El argumento básico parte de las características de la formación necesaria y
de la conveniencia de proporcionar un servicio integrado. Por ejemplo en la gestión de la
red no es conveniente aislar el soporte de las redes de área local de las de área extensa,
pues el tráfico puede atravesar varias de ellas.

£
Durante los 90 se consolidó un modelo empresarial que fue anunciado por Peter Drucker,
caracterizado por un proceso denominado “flattening”. Se traduce en un aplanamiento
de las organizaciones debido por una parte a la necesidad de tener un tiempo de
respuesta más rápido para tomar decisiones y por otra parte en aprovechar la potencia
de los Sistemas de Información para elaborar información de dirección y para transmitir
instrucciones. Con ello es posible sustituir 2/3 de los niveles situados en las líneas
intermedias.
Últimamente se ha visto conveniente distribuir las decisiones por la organización dando
autonomía a las unidades de negocio (Business Units) que disponen de presupuesto
independiente y autonomía para perseguir sus objetivos dentro de Ios estándares
señalados por la organización.
1.3 Tipos de organizaciones

Los tipos de organización vienen determinados por las tres siguientes variables:
1.3.1 Clasificación según su estructura

Las estructuras más extendidas en la mayoría de las organizaciones son las siguientes:
1.3.1.1 Estructura funcional

La estructura funcional tiene como exigencias:
1. Una coordinación más profunda entre las diferentes unidades de la organización
2. La necesidad de documentar todo con precisión
3. La necesidad de la máxima formalización
4. La existencia de una adecuada coordinación
Las ventajas de la estructura funcional son las siguientes:
x Se aprovechan mucho mejor los recursos humanos al no estar adjudicados a un
único proyecto.
x Se conoce mejor la organización desde arriba, ya que al trabajar en cadena el
fallo en cualquiera de las unidades (análisis, programación. sistemas, explotación),
se detecta inmediatamente porque las restantes unidades se ven afectadas.
x Se evita el riesgo de la dependencia excesiva de unos pocos expertos ya que
todo el mundo va trabajando en todas las aplicaciones de la organización.
Los inconvenientes de la estructura funcional son los siguientes:
x Se requiere una muy buena coordinación porque todos los departamentos deben
trabajar al unísono al no haber independencia entre ellos.
x Hay una cierta falta de especialización. Como los empleados deben trabajar en
diferentes aplicaciones no llegan a profundizar en ninguna de ellas
1.3.1.2 Estructura sectorial

La estructura sectorial tiene como exigencia fundamental que estén diferenciadas
perfectamente las distintas actividades o líneas de negocio básicas de la organización,
evitando el que los diferentes grupos tengan interferencias entre sí.
Las ventajas de la estructura sectorial son las siguientes:
x Alta especialización del personal al trabajar siempre en la misma aplicación.

£
x Autonomía de funcionamiento de cada departamento al ser independiente su

trabajo del trabajo del resto de los departamentos. Si el departamento de nómina
tiene sus técnicos de sistemas, sus analistas, sus programadores, sus programadores,
sus operadores, etc, no depende de ninguna otra unidad para poder trabajar.
x No se necesita una coordinación excesiva a alto nivel ya que cada departamento es
independiente.
Los inconvenientes de la organización sectorial son los siguientes
x Riesgo de contar con pocos especialistas que conozcan una determinada
aplicación. A veces una aplicación es llevada sólo por un analista y un programador;
y una eventual decisión suya de abandonar la organización puede provocar graves
problemas.
x Desaprovechamiento del personal. Cuando hay poco trabajo en un departamento
su personal no es aprovechado por otro departamento que estuviese desbordado de
trabajo.
1.3.1.3 Estructura mixta

En la estructura mixta se pretende coger lo mejor de las estructuras funcional y sectorial y
evitar lo peor de ambas. En una estructura mixta habrá un jefe de recursos para cada
área de Análisis, Programación, Sistemas y Producción, y varios jefes de proyecto.
El jefe de recursos asignará personal de diferente especialización, de forma temporal, a
cada uno de los proyectos. Cuando el proyecto finaliza el personal se vuelve a integrar,
dentro de su departamento, a las órdenes del jefe de recursos.
Existen además otros tipos en los que se entremezclan las estructuras anteriores con
factores como el geográfico (División en Business Units, siguiendo una estructura orientada
a negocios).
1.3.2 Clasificación según su diseño

Los tipos de diseño más extendidos son los siguientes:
1.3.2.1 Apuntado
En el modelo apuntado hay un número elevado de niveles en la pirámide jerárquica. Es el
caso de la Administración en el que desde el presidente del gobierno al jefe de grupo hay
14 niveles. En este tipo de modelo se producen grandes rigideces a la hora de la
circulación de la información.
1.3.2.2 Plano
En el modelo plano existen pocos niveles en la pirámide jerárquica lo que hace que las
organizaciones con este tipo de estructura sean mucho más flexibles y operativas que las
anteriores.
En la moderna teoría de la organización se propugna la disminución de niveles, lo cual es
muy difícil de conseguir en las organizaciones antiguas con estructuras apuntadas, ya que
en la mayoría de ellas las retribuciones van en función del nivel jerárquico.
1.3.2.3 Basado en la línea

Suelen ser organizaciones jóvenes y de pequeñas dimensiones, que tienen que dedicar
todos sus recursos a la producción. En ellas o el staff no existe o es muy limitado.

£
1.3.2.4 Con orientación a staff

Las organizaciones antiguas y grandes suelen tener una tendencia a la creación de
unidades de staff, justificándolas en la absoluta necesidad de estudiar una serie de
cuestiones que las unidades de línea, por su propia naturaleza, no podrían hacer por tener
que dedicar todo su tiempo a la producción. En las organizaciones burocratizadas las
unidades de staff llegan a crecer desmesuradamente, llegando a superar incluso a las de
línea. Hay que señalar, no obstante, que algunas unidades de staff limitadas y eficientes,
pueden ser de una enorme ayuda para la organización.
En un centro de tecnologías de la información que tenga una unidad staff dedicada al
estudio de nuevos productos software y hardware y de nuevos servicios es no sólo
conveniente sino absolutamente imprescindible. Las unidades de análisis y programación;
y las de sistemas y producción, al estar, en general, desbordadas de trabajo, no pueden
dedicar tiempo a estudiar estos aspectos.
1.3.3 Clasificación según el sistema de funcionamiento

Desde el punto de vista del funcionamiento se pueden destacar las siguientes
posibilidades:
1.3.3.1 Jerárquico
Las comunicaciones siguen siempre las líneas jerárquicas que marcan la estructura
piramidal de la organización. La mayoría de las comunicaciones, por no decir todas, se
producen de jefe a subordinados y de subordinados a jefes. Las comunicaciones
colaterales están muy restringidas.
1.3.3.2 Reticular
Son mucho más flexibles y eficientes ya que las comunicaciones entre las unidades de
empleados de la organización no tienen por qué seguir exclusivamente las líneas de
mando jerárquicas. Las comunicaciones son de todos con todos, sobre todo por niveles.
Esto hace que muchos problemas se resuelvan a nivel horizontal sin que tengan que
intervenir las líneas de mando convencionales. Estas sólo intervienen cuando las
comunicaciones reticulares de nivel horizontal no pueden resolver las cuestiones que se
planteen entre las diversas unidades jerárquicas.
1.3.3.3 Formal
En las organizaciones formales las comunicaciones suelen estar muy formalizadas y
documentadas de acuerdo a normas estrictas. Lo que no se comunique por las vías
formales establecidas no tiene validez.
Las reuniones también tienen una preparación muy formal y muy reglada con
convocatorias anticipadas, ordenes del día, entregas de documentación para la discusión
y el debate.
1.3.3.4 Informal
Hay organizaciones más informales, sobre todo las jóvenes y pequeñas, que suelen
prescindir casi totalmente de los formalismos. Esto tiene la ventaja de la agilidad y
flexibilidad de funcionamiento, pero también tiene graves inconvenientes cuando las
organizaciones empiezan a tener un tamaño considerable.

£
2.- Estructura de un departamento de Sistemas de Información

Dentro del organigrama típico de una organización se observa una tendencia a la
emancipación de la unidad informática. Esto es, aun teniendo dependencia orgánica de
otras unidades en la empresa, la función informática se organiza y gestiona
separadamente. Se definen las funciones y responsabilidades, así como la estructura
interna, y se introduce una gestión económica independiente para el departamento de
Sistemas de Información.
Sería deseable que el Departamento de Informática estuviera situado, dentro del
organigrama de la empresa, al mismo nivel que otros Departamentos de la empresa,
como pueden ser el Administrativo-Financiero, el Comercial, el de Personal o el de
Producción, sin tener dependencia jerárquica de ninguno de ellos.
Actualmente la tendencia es que el Departamento de Informática dependa de la
Dirección General, pues de este modo se consigue que la informática sirva mejor a los
intereses generales de la empresa. La fijación de prioridades se realiza de común acuerdo
entre los distintos departamentos, con la supervisión y conformidad de la Dirección.
La Organización debe estar diseñada de tal modo que facilite y favorezca la gestión de la
seguridad informática. Y esto debe cumplirse tanto dentro del propio Departamento de
Informática como en la ubicación de éste en el organigrama de la empresa.
La composición del Departamento y la definición de funciones o descripción de puestos
de trabajo debe ser tal que, además de establecer claramente los cometidos de sus
integrantes, no provoque solapamientos ni deje responsabilidades por cubrir.
2.1 Áreas del departamento
2.1.1 Área de Desarrollo

La función de que se encarga esta área se refieren al desarrollo de aplicaciones en el
campo de las Tecnologías de la Información. Las funciones básicas para el desarrollo de
aplicaciones son el análisis y la programación.
Una aplicación es un conjunto estructurado de programas informáticos cuya ejecución
sistemática permite la gestión automatizada de un procedimiento específico de una
organización. La aplicación implica también la existencia de los manuales necesarios para
que sus usuarios o los informáticos que la mantienen tengan información documentada
sobre ella.
Los puestos de trabajo relacionados son:
x Analistas
x Programadores
2.1.1.1 Análisis
El análisis es la fase, dentro del desarrollo de un sistema de información, en la que
partiendo de las especificaciones funcionales suministradas por el usuario se establecen
especificaciones técnicas a diferente nivel de detalle.
La experiencia demuestra que en una organización el conjunto de los datos base, la
materia prima de la que se va a extraer la información, y las interrelaciones entre dichos
datos base, es algo mucho más estable que las salidas de información y sus
correspondientes procesos de obtención.

£
Dentro del análisis cabe distinguir convencionalmente el análisis funcional y el análisis

orgánico.
2.1.1.1.1 Análisis funcional

Es la fase dentro del análisis de un sistema de información en la que se realizan, dentro de
un esquema de modelo conceptual de datos, las siguientes tareas:
1. Estudio del sistema de información preexistente
2. Diagnóstico del sistema preexistente
3. Diseño racional y normalizado del nuevo sistema de información
4. Determinación del modelo conceptual de datos.
5. Determinación de] modelo lógico de datos, lo cual implica definir para cada tabla
de datos los atributos o campos de la tabla.
6. Determinación de las cadenas de proceso.
7. Determinación de procesos.
8. Descripción generalizada de cada proceso.
9. Diseño de menús.
10. Diseño de pantallas.
11. Diseño de informes de salida.
12. Descripción funcional del sistema de confidencialidad.
2.1.1.1.2 Análisis orgánico

El análisis orgánico es la fase del análisis de un sistema en la que se realizan las siguientes
funciones:
1. Diseño físico del modelo de datos.
2. Descripción de cada proceso.
3. Organigrama de detalle de cada proceso en el que figuren las unidades de
tratamiento,
4. Determinación de las unidades elementales de tratamiento.
5. Esquema de detalle de cada unidad de tratamiento (programa).
6. Descripción procedural de cada unidad de tratamiento (programa).
7. Determinación de juegos de ensayo.
8. Determinación del sistema de cargas iniciales de datos.
2.1.1.2 Programación
Las tareas de programación se materializan a través del diseño y desarrollo de programas.
Un programa es un conjunto de instrucciones codificadas en un lenguaje especial
simbólico o absoluto, cuya ejecución en un sistema físico da lugar a la realización de una
tarea especifica. Para desarrollar un programa hay que llevar a cabo ciertas actividades
fundamentales:
x Definir con precisión y claridad la tarea que se quiere programar. Si una tarea está
bien definida es muy probable que su programación pueda llevarse adelante con
éxito sin excesivas dificultades. La definición de la tarea a ejecutar en el ámbito de

£
la informática científica es mucho más sencilla que en el ámbito de la informática

de gestión.
x Determinar el algoritmo óptimo de resolución de la tarea que se quiere programar.
Un algoritmo es un conjunto finito de instrucciones de actuación debidamente
ordenadas cuya ejecución sistemática en el orden preestablecido da lugar a la
ejecución de una tarea. La palabra algoritmo se deriva del nombre del
matemático oriental Al-Kuaritmi que en el siglo IX definió los algoritmos de las
operaciones elementales aritméticas en números árabes. Gracias a estos
algoritmos el mundo occidental ha podido desarrollar actividades económicas y
actividades que requerían cálculos aritméticos sin necesidad de utilizar ábacos o
instrumentos similares.
La determinación del algoritmo a utilizar para resolver una tarea es también, en
general, mucho más sencilla en la informática científico-técnica que en la
informática de gestión, ya que en la científico-técnica los algoritmos están ya
perfectamente establecidos y no hace falta hacer ningún descubrimiento ni
investigación. En la informática de gestión la determinación del correspondiente
algoritmo puede ser una tarea mucho más difícil.
La determinación del algoritmo de resolución de una tarea es una de las típicas
funciones del analista informático, aunque en esta tarea puede estar muy ayudado
por el usuario,
Ahora bien, no sólo basta con determinar un algoritmo que sea eficaz al resolver la
tarea, además es necesario que dicho algoritmo sea un algoritmo eficiente que
resuelva la tarea pero con el menor coste posible.
x Codificación de las instrucciones determinadas en el algoritmo. Una vez
determinado el algoritmo óptimo y por tanto, eficaz y eficiente, se procederá a su
codificación en aquel Lenguaje de programación más apto para el tipo de tarea
que haya que realizar. La codificación es función del programador informático.
x Una vez codificado el programa se probará hasta conseguir depurarlo de todos los
errores detectados, tanto de ortografía y sintaxis como de tipo lógico. Los errores
de tipo lógico se pueden detectar mediante un juego de pruebas construido al
efecto que simule el problema real que se requiere resolver con la ejecución del
programa.
2.1.2 Área de Sistemas

En el área de sistemas se llevan a cabo todas las funciones relativas al buen
funcionamiento y mantenimiento de los sistemas de información. Dentro de éstos habría
que destacar:
o Los lenguajes de programación
o Los sistemas de gestión de base de datos (SGBD)
o Los sistemas operativos
o Software de aplicaciones
o El Hardware
o Las comunicaciones
Los puestos de trabajo relacionados con el área de sistemas son:
Administradores de Bases de datos y Sistemas Operativos
Administradores de Servicios de Aplicaciones

£
Administradores y Desarrolladores de Infraestructuras de clave pública PKI

Administradores de Seguridad
2.1.3 Área de Producción

La producción se engloba dentro de la explotación y operación de sistemas informáticos.
Los puestos de trabajo del área de producción son los puestos de operador. Se pueden
distinguir distintos tipos de tareas que pueden clasificarse como sigue:
Operación de consolas.
Las tareas que realizan los operadores de consola son:
o Selección de trabajos.
o Control de la ejecución de los trabajos.
o Atención a los mensajes de aviso y de error.
o Bypass de los problemas.
o Control de los periféricos.
o Rearranques del sistema.
o Cambio de las prioridades de ejecución.
o Apertura y cierre del sistema.
Después de ver cuales son las tareas y desde dónde se realizan analizaremos para qué se
realizan estas tareas para poder organizarlas de la forma más adecuada. Las funciones
son:
Iniciativa en la operación. No basta con responder a los mensajes. Se debe
adoptar una actitud proactiva con objeto de prevenir la futura aparición de
errores.
Análisis de los nodos de la red de teleproceso de la instalación.
Análisis de las tareas suspendidas.
Análisis del ritmo de transacciones. Control de los “cuellos de botella”.
Cierre y arranque de los monitores y de los SGBD.
Detección de anomalías potenciales como el ritmo de I/O.
Cancelación de transacciones y terminales.
Refuerzo del cumplimiento de los estándares de usuarios.
Operación de impresoras.
Entre todos los trabajos que se realizan en Producción es el que más intervención manual
tiene en razón de la necesidad de realizar las siguientes tareas.
Transportar el papel desde sus embalajes hasta las impresoras.
Alimentar las impresoras bien con paquetes de papel continuo bien con bloques
de hojas sueltas.
En el caso de las impresoras de alta velocidad atender a las tareas necesarias
para unir el papel de diferentes cajas en un sólo continuo en aquellos listados que
sean de grandes dimensiones.
La limpieza de los elementos mecánicos de las impresoras de impacto y el
cambio del material fungible en otros tipos de dispositivos.

£
La atención a los resultados de la impresión que es necesario mantener para

asegurar que en los casos en que se utiliza papel preimpreso la alineación sea
correcta y en los casos en que se utiliza papel en blanco y se emitan listados de
gran tamaño controlar si el resultado formal de la impresión coincide con las
especificaciones. En caso contrario, avisar a los planificadores de trabajos.
Separación de los productos obtenidos de las distintas impresoras, ordenación por
clases y transporte hasta los puntos de entrega de acuerdo con los estándares de
la instalación.
Se trata por tanto del trabajo más penoso y exigente de los que físicamente se requieren
en el departamento, no sólo por el desgaste físico que supone sino por las condiciones
ambientales en que se desarrolla.
Distribución de las tareas por la organización.
Las impresoras se han distribuido por toda la organización no sólo asociadas a los puestos
de trabajo sino en forma de impresoras departamentales lo que ha supuesto una
simplificación de las tareas de la producción del Centro de Proceso de Datos que debe
entregar menos productos a menos usuarios pero éstos de mucho mayor volumen y
utilizando recursos de potencia superior.
Si necesitamos disponer además de las impresoras de calidad, de impresoras de impacto
para determinados formularios, o de impresoras láser parece lógico concentrar todas ellas
en un sólo lugar donde evidentemente deberá existir un grupo de consolas para gestionar
las colas de impresión, los rearranques y para administrar los trabajos que están en espera.
Todos los mensajes que se dirijan a estas consolas no se deberían dirigir a otros puntos de la
instalación para eliminar redundancias.
Gestión de la cintoteca.
La gestión y custodia de los soportes magnéticos ha sido una de las funciones no sólo
típicas sino básicas de las áreas de explotación tanto en su vertiente de operación corno
en lo referente a la gestión de la cintoteca.
Si hemos decidido situar en un lugar suficientemente aislado las cintotecas y las unidades
de lectura, deben concentrase allí las consolas desde las que se manejan este tipo de
periféricos.
Las tareas que deben ser realizadas para la gestión del soporte tipo cinta son:
Controlar los soportes magnéticos existentes
Escoger el tipo de periféricos que deben ser utilizados
Estandarizar el tipo de instrumentos de manipulación de los soportes
Situar la cintoteca en el lugar adecuado vigilando por la adopción de las
medidas que garanticen la integridad de la información.
Vigilar que las cintas sean almacenadas en lugares de temperatura o humedad
adecuadas, fuera de la influencia de campos magnéticos, y con un nivel de
polvo reducido.
Transportarlas ordenadamente desde la cintoteca hasta las salas de operación
en el caso de que no estén en el mismo recinto.
Identificar de forma inequívoca las cintas tanto en el soporte externo como en el
interno.
Etiquetar adecuadamente las cintas reflejando los ficheros que contiene, su
propietario, sus características como longitud de registro y de bloque, su densidad
y su fecha de caducidad. En el caso de instalaciones fuertemente automatizadas
que dispongan de herramientas de gestión de la cintateca o en que el SW de

£
control de las unidades robotizadas que los manejan, realizar esta tarea no será
preciso. En la actualidad solamente las grandes instalaciones disponen de
unidades robotizadas.
Adoptar las medidas necesarias para responder de la identificación y custodia de
estos soportes evitando su extravío.
Realizar copias de seguridad que permitan recuperar cualquier fichero no sólo en
el caso de que exista un desastre. Debe tenerse en cuenta que determinados
archivos críticos, como puede ser un backup pueden ser totalmente inutilizables e
imposibilitar por ello la recuperación de una instalación en el caso de que un
grupo de bloques de información no pueda ser recuperado por un error de
escritura. La adopción de medidas para garantizar que existan las copias
suficientes de la información crítica para evitar estas contingencias es
responsabilidad de este área.
Operación del teleproceso.
En las organizaciones tradicionales la importancia relativa del teleproceso era reducida y
el esfuerzo de la operación de consola se centraba en la planificación y el control de los
trabajos batch y en el control de las Bases de Datos.
Con la distribución de informática por las organizaciones, primero basándose en la
utilización de terminales no inteligentes conectados a un mainframe y más adelante con
arquitecturas distribuidas, el peso del proceso transaccional y del teleproceso se ha
incrementado progresivamente.
Las tareas básicas que debe realizar el personal destinado en operaciones son:
Asignar y controlar los recursos de la red.
Controlar el estado de los componentes. Debe destacarse que dado el elevado
número de recursos es imprescindible la utilización de herramientas de Gestión de
Red.
Es el segundo nivel de Gestión de Problemas.
Es conveniente que un número elevado de las incidencias se resuelvan en el Help Desk en
el primer nivel de gestión de problemas. La especial naturaleza de los problemas derivados
del mal funcionamiento de la red hace preciso disponer de monitores por lo que, o se trata
de un help desk altamente especializado o las llamadas se derivan a un grupo de analista
de soporte a la red que se encuentran en el segundo nivel.
Control de los rearranques.
La necesidad de realizar rearranques deriva de una situación de interrupción del servicio.
Las consecuencias de la interrupción son evidentemente la falta de prestación de servicios
a los usuarios y un deterioro de los niveles de prestación. Esto puede suponer una
vulneración de los acuerdos establecidos de nivel de servicio, con las repercusiones
económicas que de ello se pudieran derivar.
2.1.4 Area de redes y comunicaciones

El entramado conceptual que constituyen los nodos de la red, las líneas, los
concentradores, multiplexores, redes locales, etc. no son sino el soporte físico-lógico de los
procesos de la organización en tiempo real. Este sector requiere un equipo de
especialistas, expertos simultáneamente en Comunicaciones y en Redes Locales (no hay
que olvidarse que en entornos geográficos reducidos, algunas empresas optan por el uso
interno de Redes Locales diseñadas y cableadas con recursos propios).
Esta sección se encarga de lo siguiente:

£
o Instalación y Mantenimiento de la red

o Medida de los índices de utilización de las líneas, y los tiempos de desuso
o Gestión del Sistema de interconexión entre redes (internetworking)
o Gestión de la conexión a Internet y del dominio
o Instalación y Mantenimiento de los servicios telemáticos de Comunicaciones (DNS,
Correo-E, listas distribución, accesos remotos, etc)
o Instalación y Mantenimiento de los servicios telemáticos de Información (Servicios de
Información WWW, News, FTP, Proxy-Caché, Directorio, servicios WWW, Indexación,
Multimedia)
o Correo Electrónico Internet (E-mail)
Deberá tenerse documentación actualizada sobre la topología de la red de
comunicaciones. La contratación e instalación de líneas va asociada a la instalación de
los puestos correspondientes (servidores, computadoras con tarjetas de comunicaciones,
impresoras, etc.). Todas estas actividades deben estar coordinadas y a ser posible, ser
dependientes de una sola organización.
Los puestos de trabajo relacionados son:
Administrador de Servicios Telemáticos
Administrador de Red
Técnico Especialista en Sistemas de Cableado
2.1.5 Area de atención al usuario

Se ocupa de la gestión de actualizaciones, el soporte a los usuarios, la gestión del acceso
a recursos comunes y la formación acerca de la operación y utilización de los sistemas de
información.
2.1.6 Area de administración y servicios

La misión de esta área es la de apoyo administrativo de la Coordinación Informática y sus
dependencias. Sus funciones primordiales son:
Recibir, registrar, distribuir, controlar y archivar la documentación del Centro de
Cómputo
Administrar el Stock de consumibles, iniciando los trámites de adquisición.
Ayudar en el uso y adquisición de la bibliografía requerida
2.2 Unidad de seguridad

Salvo en el caso de la existencia de un grupo específico de Gestión de Seguridad o de
Auditoría dependiendo directamente del Director del Centro de Proceso de Datos, es
habitual que el conjunto de tareas necesarias para garantizar la integridad física de los
elementos necesarios para la explotación corresponda al área de explotación.
2.3 Unidad de calidad

La organización debe contar con un Sistema de Calidad debidamente documentado que
se mantenga permanentemente actualizado. La existencia de este Sistema de Calidad le
permite asegurarse que los servicios que ofrece a sus clientes usuarios están conformes con
las normas internacionales de calidad.

£
El Sistema de Calidad es el conjunto de elementos que definen la estructura,

organización, responsabilidades, sistema documental y medios necesarios para la
implantación y gestión de la calidad. Se basa en los siguientes aspectos:
- La organización de los recursos humanos y técnicos.
- La documentación de los procesos, procedimientos e instrucciones de trabajo.
- La valoración de los resultados y mediciones de la calidad de sus procesos.
- Las auditorías internas de la Calidad.
- La formación de los empleados.
La valoración de los resultados y mediciones de la calidad de los procesos
El control de parámetros internos de control, perfectamente objetivables y medibles,
permite conocer el estado de los procesos que configuran las actividades que la
organización presta a sus clientes usuarios.
Este sistema de mediciones, al permitir detectar desviaciones en los procesos, facilita el
análisis de las causas de las mismas y la toma de las oportunas acciones correctoras o
preventivas que, una vez implantadas, permiten la optimización de los procesos.
Los Procedimientos de control e inspección describen la operativa a seguir para
materializar este tipo de valoraciones.
Auditorías internas de la Calidad
Un Plan anual de Auditorías que aprueba el Comité de Calidad permite valorar la
efectividad y el grado de cumplimiento del Sistema de Calidad, constituyendo un
magnífico complemento de los indicados sistemas de mediciones y de inspección ya que
aporta una visión preventiva a las posibles desviaciones de los procesos.
Las auditorías son realizadas de manera regular de acuerdo al citado Plan, y son
planificadas en función de la criticidad de cada área. Su realización corre a cargo de
personal debidamente adiestrado e independiente de las tareas auditadas.
Plan de Formación
Un Plan de Formación recoge las necesidades de formación de los empleados en función
de los objetivos y estrategias de la organización y del grado de formación del propio
empleado. El cumplimiento de este Plan es fundamental para asegurar un correcto
desarrollo de las diferentes actividades y procesos.
La aprobación de dicho plan corresponde a la unidad de Calidad así como su
seguimiento regular.
2.4 Organización de reuniones

Las reuniones de los órganos deben organizarse bajo los siguientes postulados:
1. Debe haber un orden del día concreto, realista y anticipado.
2. La documentación aportada debe ser sintética, completa y anticipada
3. Los asistentes no deben ser demasiado numerosos
4. La duración no debe exceder las dos horas
Funcionalmente debe existir una introducción, puntos- intervención, participación y
conclusiones y/o acuerdos. Siempre se puede contar con medios audiovisuales para
utilizar durante la marcha de la reunión.
De todas las reuniones se debe elaborar un memorandum sintético en el que se recojan las
conclusiones y acuerdos, para enviar a todos los asistentes.

£

£
3.- Roles y responsabilidades. Segregación de tareas

Para un buen funcionamiento del Centro de Sistemas de Información hay que definir los
puestos de trabajo indicando las funciones y las dependencias entre ellos.
Se pueden definir varias cualidades tipo que reúne el personal informático, tanto en
formación como en aptitudes. Como cualidades fundamentales están la capacidad de
abstracción, la lógica y el sentido del detalle.
Siendo el personal el activo más importante de la organización, parece razonable que
exista una política adecuada, abarcando todos los aspectos (contratación,
remuneración, información, motivación, incentivación, formación, reciclaje, etc.) que
favorezca la obtención no sólo del máximo rendimiento de las personas sino también de su
integración y realización dentro de la organización. Es vital contar con personal sobre el
que poder depositar la confianza.
A continuación se detallan algunos puestos de trabajo de la función informática:
3.1 Director de Tecnologías de Información

También llamado Director de Informática, Jefe de Informática, Director de Sistemas de
Información.
Para que haya una gestión eficaz de la compañía deberá elaborar, planificar,
implementar y mantener los sistemas, procesos, circuitos y procedimientos de información
necesarios.
3.1.1 Funciones
o Gestionar la política de tecnologías de la comunicación para que sea adecuada a
los objetivos y necesidades de la empresa.
o Formular y proponer el plan informático según los objetivos de la empresa, a corto,
medio y largo plazo.
o Instaurar las soluciones informáticas necesarias para cubrir las necesidades de la
empresa y de sus usuarios.
o Supervisar la implementación y desarrollo de los proyectos informáticos.
o Negociar con los proveedores lo relativo a servicios y productos informáticos.
o Cooperar en el diseño de planes de formación en materia de tecnologías de la
información y supervisar su implementación.
3.1.2 Competencias
o Conocimientos de planificación estratégica de sistemas de información
o Conocimientos de tecnologías informáticas, mercado de hardware y software.
o Flexibilidad de criterios
o Habilidades para la obtención y análisis de información
o Orientación al cliente (interno/externo)
o Interés por la Innovación

£
o Capacidad de síntesis
o Perspectiva estratégica
3.2 Analista
Realiza tareas de creación y análisis de sistemas informáticos.
3.2.1 Funciones
o Desarrollar la información obtenida mediante la informática
o Investigar, perfeccionar, idear o desarrollar conceptos y métodos informáticos,
trabajando en su aplicación o asesoramiento.
o Realizar investigaciones acerca de los principios y métodos informáticos.
o Desarrollar y mantener los soportes lógicos y programas, y la estructura y sistemas de
datos
o Mantener actualizados y en buen funcionamiento las bases de datos y los sistemas de
gestión de datos par garantizar la validez e integridad de la información registrada.
o Analizar las necesidades de los usuarios y determinar programas, configuraciones y
soportes lógicos.
o Idear, desarrollar y mantener, y perfeccionar los programas lógicos que rigen el
funcionamiento general de las computadoras.
o Crear y desarrollar lenguajes informáticos.
3.2.2 Competencias
o Conocimientos de programación
o Conocimientos de tecnologías informáticas, mercado de hardware y software
o Habilidades para la obtención y análisis de información y para enfocar la atención
3.3 Programador
Se ocupa del desarrollo y mantenimiento de sistemas.
3.3.1 Funciones
o Elaborar, desarrollar, ensayar y mantener en buen estado los soportes lógicos y/o los
programas informáticos, para cubrir las necesidades de los usuarios.
o Determinar en colaboración con los Analistas informáticos los objetivos perseguidos
con los distintos programas, la naturaleza y fuentes de datos que habrá que introducir
y ordenar, y establecer los controles necesarios.
o Elaborar gráficos y diagramas para describir y determinar en que secuencias habrá
que proceder al registro y tratamiento de los datos.
o Desarrollar y proporcionar documentación detallada sobre los programas
informáticos, utilizando par ello diversos lenguajes de programación.
o Ensayar los programas elaborados para eliminar o corregir deficiencias o errores.
o Mantener actualizados los programas.

£
3.3.2 Competencias
Las mismas que las del analista:
o Conocimientos de programación
o Conocimientos de tecnologías informáticas, mercado de hardware y software
o Habilidades para la obtención y análisis de información y para enfocar la atención
3.4 Operador
Es el personal dedicado a la operación del sistema.
3.4.1 Funciones
Operador de Ordenador es quien se encarga del manejo de los distintos dispositivos del
ordenador. Interpreta y desarrolla las órdenes recibidas para su explotación correcta,
controla la salida de los trabajos y transmite al Gestor de Sistemas las anomalías físicas o
lógicas observadas.
Operador de Terminal es quien realiza las funciones de toma o verificación de datos a
través de terminales inteligentes, debiendo controlar en modo conversacional los formatos
y códigos requeridos por los programas correspondientes.
3.5 Administrador de Base de Datos
3.5.1 Funciones
o Definición de necesidades de equipo y software de base de datos
o Mantenimiento y especificación de la estructura de la base de datos
o Preparación de definiciones normalizadas de datos
o Análisis de rendimiento de la base de datos
o Implementación de permisos de acceso
o Definición de procedimientos de seguridad

£
Tema III.II.4. Los lenguajes de control de trabajos: Concepto,

estructura, elementos y funcionalidades. Las
técnicas y herramientas de operación automática.
Índice
1.- INTRODUCCIÓN................................................................................................................................ 2
1.1 Componentes de un Sistema Operativo (SO) ..................................................................... 2
1.2 Evolución de los Sistemas Operativos.................................................................................. 4

1.2.1 Proceso en serie ......................................................................................................................................4
1.2.2 Sistemas Sencillos de Proceso por Lotes .............................................................................................4
1.2.3 Sistemas por Lotes con Multiprogramación .......................................................................................6
1.2.4 Sistemas de Tiempo Compartido .........................................................................................................6
2.- LENGUAJES DE CONTROL DE TRABAJOS (JOB CONTROL LANGUAGE - JCL) ............................... 7
2.1 Funcionalidad......................................................................................................................... 7
2.1.1 Control de Ejecución de Trabajos........................................................................................................7
2.1.1.1 Interbloqueos....................................................................................................................................8
2.1.1.2 Sincronización de Procesos ...........................................................................................................9
2.1.1.3 Subsistema de Entrada de Trabajos (JES - Job Entry Subsystem)..........................................10
2.1.1.3.1 Mecanismos de Control del JES........................................................................................................12
2.1.2 Control de Incidencias en Trabajos ...................................................................................................13
2.1.2.1 Control de Entrada de Trabajo ...................................................................................................13
2.1.2.2 Asignación de Clases....................................................................................................................13
2.1.2.3 Prioridades de Selección y de Ejecución..................................................................................14
2.1.2.4 Comunicación con el Operador................................................................................................14
2.1.2.5 Ejecución Condicional .................................................................................................................15
2.1.2.6 Rearranque de Trabajos...............................................................................................................15
2.2 Estructura y Elementos (Sentencias JCL) ........................................................................... 16

2.2.1 Sintasis Básica de las sentencias JCL.................................................................................................16
2.2.1.1 Continuación de Sentencias.......................................................................................................17
2.2.1.2 Comentarios ...................................................................................................................................17
2.2.2 Tipos de Sentencias ..............................................................................................................................17
2.2.2.1 Sentencia JOB ................................................................................................................................17
2.2.2.2 Sentencia EXEC..............................................................................................................................18
2.2.2.3 Sentencia de Definición de Datos (Data Definition - DD)......................................................18
2.2.2.3.1 Sentencia DD para Entrada de Datos .............................................................................................18
2.2.2.3.2 Sentencia DD para ficheros de datos en Disco .............................................................................18
2.2.2.3.3 Sentencia DD para ficheros de datos en Cinta Magnética ........................................................19
2.2.2.3.4 Sentencia DD para Salida de Datos en impresora.......................................................................19
2.2.3 Sentencias de Salida ............................................................................................................................19
2.2.4 Sentencias JES3 de Control .................................................................................................................20
2.2.4.1 Sentencia //*MAIN ........................................................................................................................20
2.2.4.2 Planificación de Trabajos .............................................................................................................20
2.2.4.3 Sentencia //*OPERATOR...............................................................................................................21

£
1.- Introducción
JCL (Job Control Language) es un lenguaje para la descripción, organización y ejecución
de trabajos en el sistema MVS, OS/390 y sistemas operativos (SO) tipo VSE, que se ejecutan
en los servidores de gran tamaño (mainframes) tipo S/390 de IBM. Los SOs asignan su
tiempo y recursos en función de la cantidad total de trabajos que han sido iniciados en el
ordenador. Los trabajos, por su turno, se dividen en entidades menores llamadas pasos o
unidades individuales que se ejecutan en background (también llamados batch o lote) sin
necesidad de ningún tipo de intervención por parte del operador. Adicionalmente, el SO
maneja solicitudes de trabajo por parte del usuario del tipo interactivas (foreground).
Generalmente, los trabajos interactivos tienen prioridades más altas que los del tipo batch.
Las sentencias (statements) JCL especifican, principalmente, el conjunto de datos de
entrada (archivos) que deben de ser usados, el conjunto de datos de salida adonde
residirá el resultado del trabajo, los recursos necesarios para llevar a cabo la tarea, y los
programas utilizados. El conjunto mismo de sentencias JCL relacionado con el trabajo es
almacenado en un fichero y puede ser iniciado de manera interactiva. Los sistemas MVS y
OS/390 disponen de un interfaz interactivo tipo menú, el ISPF, para inicio y gestión de
trabajos.
En MVS y OS/390, la parte del SO que maneja JCLs es llamada JES (Job Entry Subsystem –
Subsistema de Entrada de Trabajos), que existe en dos versiones: JES2 y JES3, con
capacidades adicionales para la gestión de los trabajos.
1.1 Componentes de un Sistema Operativo (SO)

Los sistemas de propósito general se caracterizan por tener un gran número de usuarios
trabajando sobre un amplio abanico de aplicaciones. Están diseñados para mantener un
flujo constante de trabajo en forma de tareas a ejecutar. Como las tareas a realizar serán
muy diversas, deberán soportar un gran número de utilidades (compiladores, editores,
ensambladores, paquetes de depuración, procesadores de texto, sistemas de ficheros
para almacenamiento a largo plazo, etc...) y de periféricos.
Su control y disponibilidad junto con la organización del flujo de trabajo es su principal
función. En estos sistemas se combinan sistemas 'batch' (locales o remote job entry) y
sistemas de acceso múltiple (el usuario desde un terminal lanza, dirige y controla la
ejecución), aprovechando lo primero para actividades rutinarias no interactivas.
Un sistema operativo crea el entorno en el que se ejecutan los programas, ofreciendo a los
programas y a los usuarios una serie de servicios. Antes de comenzar el diseño del sistema,
sus objetivos deberán estar bien definidos ya que serán la base de toma de decisiones de
diseño, tales como la elección de algoritmos y estrategias.
La construcción de sistemas operativos modernos requiere la división de los mismos en
diferentes partes con funciones claramente diferenciadas y con interfaces de entrada y
salida adecuados. Los servicios específicos ofrecidos por los sistemas operativos varían de
unos a otros, pero existen algunas clases de servicios que son comunes y que pueden
identificarse claramente.
Gestión de procesos
El sistema realiza varias actividades simultáneamente que compiten por la utilización de
determinados recursos, entre los que destaca la CPU, estas actividades se denominan
procesos. Un programa, por si solo, es una entidad pasiva mientras que un proceso es una
entidad activa ya que compite por los recursos máquina. El proceso es una unidad de

£
trabajo del sistema y el sistema operativo es el responsable de realizar un seguimiento de

todas las actividades del sistema en conexión con los procesos generados. Para ello crea y
destruye procesos, suspende y reanuda su ejecución, ofrece los mecanismos de
sincronización y comunicación y permite la espera durante la ejecución de un proceso.
Gestión de memoria
Existen diversos esquemas para gestionar la memoria de un sistema, la cual es vital para el
funcionamiento del mismo. Generalmente, la elección de uno u otro esquema depende
de las posibilidades hardware.
El sistema operativo es por tanto responsable de registrar el uso que se hace de una
determinada parte de memoria, decidir qué procesos deben ser cargados en memoria
para ejecución y ser capaz de ocupar o liberar el espacio de memoria que utilizan los
procesos.
Gestión del almacenamiento
La memoria real instalada suele ser insuficiente para acomodar todos los datos y
programas permanentemente; el sistema debe proporcionar mecanismos de gestión de
almacenamiento secundario para soportar este almacenamiento. El sistema operativo es
responsable de gestionar el espacio libre en los dispositivos, localizar los espacios de
almacenamiento y planificar la utilización del disco.
Gestión de entradas y salidas
El sistema de entradas y salidas consiste en un sistema de 'buffering', los drivers e interfaces
necesarios para los dispositivos (solamente los drivers conocen las características
especificas de los dispositivos).
Gestión de ficheros
El sistema operativo ofrece una visión uniforme de todo el espacio de almacenamiento
disponible abstrayendo las características físicas de cada dispositivo y definiendo una
unidad lógica de almacenamiento que es el fichero. El sistema operativo es por tanto el
responsable de la creación y borrado de ficheros y directorios, de proporcionar las
primitivas necesarias para su utilización y de ‘mapear’ los ficheros sobre el espacio de
almacenamiento.
Gestión de protección
La protección incluye los mecanismos que controlan el acceso de los programas, procesos
y usuarios a los recursos del sistema. Todos los recursos del sistema deben ser manipulados
solamente por aquellos procesos autorizados por el sistema operativo. Se debe asegurar
que cada proceso sólo utilice su espacio de direcciones, y tenga el control de la CPU un
espacio de tiempo determinado.
Comunicaciones
Los distintos procesadores existentes en un sistema distribuido, deben conectarse mediante
redes de telecomunicación que se pueden configurar de diferentes maneras. El sistema
debe ofrecer al usuario acceso a los diferentes recursos pese a su distribución geográfica;
habitualmente se generaliza el acceso a la red como un acceso a un tipo de fichero
especial. La gestión de las comunicaciones incluye el ‘enrutamiento’, las estrategias de
conexión y las soluciones a problemas de contención y seguridad.
Intérprete de comandos
Es uno de las partes más importantes de los sistemas operativos actuales, y proporciona la
posibilidad de comunicación, mediante comandos, con el sistema operativo; su función
consiste en obtener una nueva orden, interpretarla y atenderla.

£
1.2 Evolución de los Sistemas Operativos
1.2.1 Proceso en serie

En los primeros ordenadores, desde finales de los 40 hasta mediados de los 50, el
programador interactuaba directamente con el hardware; no había sistema operativo. Se
disponía de una consola con indicadores luminosos y conmutadores, un dispositivo de
entrada (un lector de tarjetas, por ejemplo) y una impresora. Los programas en código
máquina se cargaban desde el dispositivo de entrada y su resultado aparecía por la
impresora en caso de no producirse ningún error. De producirse, se paraba el programa y
la condición de error aparecía en los indicadores luminosos. El programador podía
entonces examinar los registros y la memoria principal para detectar el error.
Estos sistemas presentaban dos problemas principales:
Planificación - Se utilizaba un formulario de reserva de tiempo de máquina (por medias
horas, por ejemplo) lo que daba lugar a pérdidas de tiempo de máquina cuando se
terminaba antes del tiempo reservado o bien a tiempos inútiles cuando no se había
terminado y había que finalizar porque expiraba el tiempo reservado.
Tiempo de preparación - Para cada programa (trabajo) había que cargar el
compilador y el programa fuente en memoria, salvar el programa objeto resultante,
montar y cargar el programa objeto junto a las funciones comunes para proceder a su
ejecución. Si en este proceso se producía algún error había que volver al principio del
proceso de preparación. Esto producía grandes pérdidas de tiempo.
Este modo de operación se conoce como proceso en serie porque los usuarios tenían que
acceder al ordenador en serie. Con el tiempo se desarrollaron diversas herramientas de
software de sistema como bibliotecas de funciones comunes, montadores, cargadores,
depuradores y rutinas de manejo de E/S que estaban disponibles como software común
para todos los usuarios.
1.2.2 Sistemas Sencillos de Proceso por Lotes

Inicialmente, todos los ordenadores eran del tipo mainframe, i.e. no existían los
ordenadores como los conocemos hoy. Cuando alguien escribía un programa, lo hacía
utilizando punched cards que básicamente eran tarjetas de cartulina con agujeros
representando el conjunto de instrucciones en código de máquina en binario. Un
programa solía estar compuesto por centenas o millares de estas tarjetas.
Eran los siguientes los pasos para la ejecución de un programa:
Cuando el programador se disponía a ejecutar su programa, tenía que llevar todas las
tarjetas y dejárselas al operador del mainframe.
Los programas no eran ejecutados inmediatamente: para aumentar la eficiencia, se
prefería acumularlos y ejecutarlos de una sola vez.
Como las tarjetas no contenían indicaciones del lenguaje en que estaban escritos los
programas, el operador se cargaba de insertar tarjetas de control para indicárselas al
mainframe, así como adonde empezaban y terminaban los programas. Este conjunto
de tareas se pasó a llamar trabajo. La siguiente figura muestra la configuración final de
las tarjetas para la ejecución dos programa encadenados escritos en FORTRAN y
COBOL:

£
Donde:
*$End Job
*$Run program
$Start Job - Inicio de un
trabajo.
*$Program Data $Load x Compiler - Cargar el

compilador para el lenguaje
*$Load COBOL
compiler x.
*$Start Job
$Program Data - Ficheros de
*$End Job datos de entrada y salida,
*$Run program
programas y demás recursos.
$Run program - Iniciar
ejecución de los programas.
*$Program Data
$End Job - Fin del trabajo.
*$Load FORTRAN
compiler
*$Start Job
Las tarjetas eran entonces introducidas en el ordenador para llevar a cabo su

procesamiento.
Las tarjetas especiales añadidas por el operador son parte del lenguaje JCL e indican el
inicio y final de los trabajos, los compiladores necesarios para procesar los datos, que
recursos se requieren (impresoras, etc.), el autor del programa, quien será facturado
(tiempo de procesamiento solía ser un recurso muy escaso y caro) y mucho más.
La creación de los trabajos y su encadenamiento uno detrás de otro en el sistema se llama
procesamiento en lote (batch processing) y es todavía utilizado hoy, obviamente sin los
punched cards. Si, por ejemplo, una empresa necesita procesar 30 millones de
declaraciones de la renta, estas son encadenadas y procesadas en secuencia. Los
métodos son los mismos que los descritos anteriormente, siendo la única diferencia la
tecnología utilizada: se ha ganado en velocidad.
Para empezar el procesamiento de las tarjetas, los mainframes tenían que mirar cada
tarjeta separadamente para decidir que acción tomar. En el ejemplo de arriba, se
necesitaría cargar el compilador de Fortran, posiblemente de una cinta magnética o de
memoria si ya hubiera sido cargado con anterioridad. Es importante notar que los
mainframes no podían lidiar más de un trabajo a la vez, o sea, trabajaban de manera
serial.
La ausencia de un mecanismo que pudiera gestionar la eficaz utilización de los recursos
(ej. programadores maliciosos) y errores de programación (ej. bucles infinitos) y la
consecuente intervención manual por parte del operador, indujo a que una serie de
programas fueran desarrollados, constituyendo un cuerpo, a posteriori, vino a llamarse
Sistema Operativo - SO. Ello propició a que el operador se encargara de otras tareas,
dejando a los mainframes la de mantener el buen flujo de los trabajos. Al SO se le dejó los
deberes de alocar recursos y tiempo de procesamiento, cargar los gastos a las debidas
cuentas, y chequear los niveles de acceso (los usuarios podían utilizar recursos distintos,
dependiendo de la importancia y disponibilidad).

£
Sin embargo, los trabajos todavía eran encaminados de manera serial. Si la tarea consistía
en imprimir un fichero, todo el sistema se paraba y dedicaba sus recursos a ello, mientras
otros programas, algunas veces de más rápido procesamiento, se quedaban en la cola
esperando su turno. Al SO, entonces, se le capacitó para no realizar la impresión en la
impresora directamente, mas enviar todos los comandos de impresión a un fichero para
ulterior procesamiento, permitiendo al mainframe trabajar más rápido y optimizar el uso de
los recursos. Este sistema se pasó a llamar SPOOLING (Simultaneous Peripheral Output On
Line).
A partir de entonces, sucesivas mejoras fueran incorporadas a los sistemas operativos,
como las que se destacan a seguir:
Protección de memoria - El hardware debería detectar cualquier intento de acceder a
la zona donde está el monitor, abortar el trabajo y ceder el control al monitor.
Temporizador - Impide que un trabajo monopolice el sistema. Una vez expirado el
tiempo, se produce una interrupción y el control vuelve al monitor.
Instrucciones privilegiadas - Sólo las puede ejecutar el monitor (por ejemplo las
instrucciones de E/S). Si el hardware encuentra una instrucción privilegiada en un
programa de usuario, se producirá una interrupción y el control volverá al monitor.
Interrupciones - Permiten ceder y retomar el control.
1.2.3 Sistemas por Lotes con Multiprogramación

Aún con el secuenciamiento automático de los trabajos en un sistema operativo por lotes,
el procesador está desocupado a menudo. La razón es que los dispositivos de E/S son
lentos comparados con el procesador y éste debe esperar que concluya la operación de
E/S antes de poder continuar.
Esto se puede evitar mediante la multiprogramación o multitarea, punto central de los
sistemas operativos modernos. La idea es almacenar varios programas de usuario en
memoria principal y cuando un trabajo necesita realizar una E/S se conmuta a otro
procediéndose a su ejecución. Se consigue aumentar la productividad del sistema
(trabajos por unidad de tiempo) y disminuir el tiempo medio de respuesta.
La característica más útil es que el hardware respalde las interrupciones de E/S y el DMA
(acceso directo a memoria) para que el procesador pueda enviar una orden de E/S para
un trabajo y continuar con la ejecución de otro. Para tener varios trabajos listos para
ejecutar deben mantenerse en memoria principal lo que requiere cierto tipo de gestión de
memoria. Además el procesador debe elegir entre los procesos listos cuál va a ejecutar, lo
que requiere un algoritmo de planificación.
1.2.4 Sistemas de Tiempo Compartido

Con la multiprogramación, el tratamiento por lotes llega a ser bastante eficiente. Sin
embargo, para muchas tareas, es conveniente proporcionar un modo en el que el usuario
interactúe directamente con el ordenador. Tal es el caso del proceso de transacciones. En
los años 60 los ordenadores eran grandes y costosos por lo que en lugar de utilizar una
máquina dedicada para cada usuario (como se suele hacer hoy en día) se desarrollaron
las técnicas de tiempo compartido. Se utiliza la multiprogramación para manejar varias
tareas interactivas, compartiendo el procesador entre ellas. Si hay n tareas a cada una de
ellas le corresponde 1/n de atención efectiva del procesador (sin contar la sobrecarga del
sistema operativo). Los usuarios utilizan simultáneamente el sistema mediante terminales y
el sistema operativo intercala la ejecución de cada programa de usuario en ráfagas
cortas de cómputo o cuantos (quantum). Vemos que la multiprogramación se utiliza tanto
en sistemas por lotes con multiprogramación como en sistemas de tiempo compartido
pero hay algunas diferencias:

£
Multiprogramación por lotes Tiempo compartido

Objetivo principal Maximizar la utilización del Minimizar el tiempo de respuesta
procesador
Origen de las instrucciones Instrucciones JCL junto al trabajo Órdenes introducidas desde el
terminal
El tiempo compartido y la multiprogramación plantean multitud de problemas nuevos:

evitar interferencias de los trabajos en memoria, protección de archivos frente a otros
usuarios, contención de recursos, etc.
2.- Lenguajes de Control de Trabajos (Job Control Language - JCL)
2.1 Funcionalidad
2.1.1 Control de Ejecución de Trabajos

La palabra trabajo en la terminología informática significa unidad de ejecución, es decir,
un conjunto de pasos que se ejecutan secuencialmente, consistiendo cada paso en la
ejecución de un programa. Esta definición se ajusta con exactitud al concepto de trabajo
por lotes (batch), pero en un ordenador también se procesan trabajos interactivos (que
normalmente se llaman transacciones), que suponen la ejecución de un programa
aislado, es decir, no hay una secuencia de pasos. Sin embargo, la principal diferencia
entre un trabajo batch y uno interactivo no está en el número de pasos sino en el tiempo
de ejecución y en la relación entre el trabajo y el usuario. El tiempo de ejecución suele ser
relativamente largo para un trabajo batch (puede ser del orden de minutos o de horas) y
relativamente corto para un trabajo interactivo (normalmente menos de un minuto). Por
otra parte, en el caso de trabajos interactivos, el usuario espera delante de un
videoterminal a que termine la ejecución de la transacción y normalmente ejecuta otra
transacción según el resultado de la anterior, a diferencia del trabajo batch, en el que el
usuario solamente ordena su ejecución y puede continuar haciendo otras cosas mientras
se ejecuta el trabajo.
TRABAJO
Paso1/Programa1 Paso2/Programa2 PasoN/ProgramaN
Proc1 ProcM Proc1 ProcT Proc1 ProcX

£
Cuando un programa comienza a ejecutarse, el sistema operativo crea un proceso (o

tarea) asignando una zona de memoria para el código y los datos del programa. Este
bloque de memoria es la materialización del proceso, ya que define su estado en cada
momento. Conforme el programa se ejecuta, sus datos van modificándose. Cuando el
programa es interrumpido, el estado del proceso queda fijo temporalmente. Cuando el
programa termina, se borra el proceso.
Aunque puede parecer que existe una relación biunívoca entre programas y procesos, en
realidad la ejecución de un programa puede suponer la existencia de más de un proceso.
En primer lugar, el programa puede ser concurrente, es decir, que tiene varias partes que
se ejecutan en paralelo, dando lugar cada una de estas partes a la creación de un
proceso. Y en segundo lugar, aunque el programa sea secuencial, el sistema operativo
puede crear además del proceso principal, otros procesos auxiliares cuando el programa
ejecute alguna operación de entrada/salida o realice alguna llamada a algún servicio del
sistema. En estos casos, el proceso principal quedará suspendido mientras se realiza la
operación de entrada/salida o, en general, se resuelve la petición de algún servicio al
sistema operativo.
El sistema operativo utiliza para la gestión de cada proceso un área de memoria
denominada bloque de control de proceso (Process Control Block - PCB). Estas áreas
contienen, entre otros, los siguientes datos: identificador del proceso, estado, dirección de
memoria del código y de los datos del proceso, y copia del contenido de los registros de la
CPU cuando se suspende la ejecución del proceso.
Los posibles estados en los que se puede encontrar un proceso son los siguientes:
Estado Concepto
En ejecución Cuando está utilizando la CPU.
En espera Cuando el proceso está esperando a que ocurra algún

evento, como por ejemplo, la finalización de una
operación de E/S que ha solicitado.
Preparado para ejecutar Cuando el proceso está esperando a que el SO le permita

utilizar la CPU.
2.1.1.1 Interbloqueos
Si un proceso se encuentra indefinidamente en estado de espera por algún recurso que
está asignado a otro proceso, que a su vez está esperando por algún recurso asignado al
primer proceso se produce una situación de interbloqueo o deadlock. Esta situación es
generalizable a más de dos procesos. Por ejemplo, en el caso de tres procesos, se puede
dar la siguiente situación de deadlock: el proceso A tiene asignado el recurso 1 y espera
por el recurso 2, el proceso B tiene asignado el recurso 2 y espera por el recurso 3, y el
proceso C tiene asignado el recurso 3 y espera por el recurso 1.
Algunos mecanismos teóricos para evitar los deadlocks son los siguientes:
Prohibir que un proceso espere por un recurso si ya tiene algún otro recurso asignado.
Esto implica que cuando se asigna a un proceso un recurso (de los que se tienen que
asignar en exclusiva a un proceso), es necesario asignarle todos los recursos del sistema
que implican exclusividad.
Exigir que los recursos se soliciten en un orden determinado. Las situaciones de
deadlock que se han descrito anteriormente no se pueden dar si todos los procesos
tienen que solicitar los recursos 1, 2 y 3 en ese orden.

£
Exigir que los procesos declaren previamente el número total de recursos que precisan.
De este modo, hasta que no obtienen todos los recursos que necesitan no comienza su
ejecución.
Estos mecanismos son muy restrictivos respecto al uso de los recursos y no se emplean en la
práctica.
La forma más simple de evitar los deadlocks es prohibir que un proceso espere
indefinidamente por un recurso. Para realizar esto, se establece un periodo de tiempo
máximo de espera (llamado “time out”).
Una vez transcurrido este tiempo, el proceso es cancelado por el sistema operativo,
liberando los recursos que tuviera asignados. Este mecanismo es aceptable en la mayoría
de los casos, solamente si los deadlocks se producen con mucha frecuencia o si existen
procesos críticos que no deben ser cancelados, tendría que emplearse alguna técnica
más sofisticada.
Algunos sistemas operativos vigilan cada cierto tiempo si existe algún deadlock, y cuando
lo detectan cancelan a alguno de los procesos implicados, aunque no se haya alcanzado
el tiempo máximo de espera. Esta técnica es compatible con la del time out, de hecho la
cancelación por time out se puede producir aunque no exista una situación de deadlock,
por ejemplo cuando un recurso deja de estar disponible por algún error físico o porque se
haya determinado un tiempo máximo de ejecución para un proceso.
2.1.1.2 Sincronización de Procesos

Cuando dos o más procesos se relacionan entre ellos, es necesario que exista algún
mecanismo de sincronización entre procesos. Estos mecanismos se basan en el traspaso de
información a través de zonas de memoria que puede utilizar cualquier proceso, pero
precisamente por ser zonas de acceso público es necesario que sólo haya un proceso que
modifique la información compartida a la vez. De lo contrario, los datos utilizados para la
sincronización podrían ser inconsistentes. El sistema operativo proporciona servicios que
permiten la sincronización de procesos, evitando que se produzcan estas situaciones.
Algunos de estos servicios son los siguientes:
Funciones wait y signal
Un proceso llama a la función wait cuando quiere esperar a que ocurra un evento
determinado (cuyo identificador debe pasar como parámetro). Su resultado es que el
sistema operativo sitúa al proceso en estado de espera hasta que ocurra dicho
evento.
La función signal es llamada por un proceso cuando quiere señalar la ocurrencia de un
evento. El sistema operativo situará a los procesos que estaban esperando dicho
evento en la cola de procesos preparados para ejecutar.
Para evitar que un proceso espere indefinidamente por un evento que no se va a
señalar nunca o que se ha señalado previamente, existe la posibilidad de definir un
time out o tiempo máximo de espera.
Paso de mensajes (send y receive)
Con la función send un proceso envía información (un bloque de caracteres) a otro
proceso. Con la función receive un proceso recibe la información enviada por otro.
Existen distintas formas de realizar estas funciones. Por ejemplo, la función send puede
esperar la confirmación de la recepción del mensaje o puede seguir su ejecución sin
esperar; la función receive normalmente implica que el proceso espere si no hay ningún
mensaje y que el mensaje se borre una vez recibido.

£
2.1.1.3 Subsistema de Entrada de Trabajos (JES - Job Entry Subsystem)

Los sistemas operativos de grandes ordenadores suelen utilizar un subsistema de entrada
de trabajos, que se encarga de las siguientes funciones: planificación “a largo plazo” de
los trabajos, introducir los trabajos al subsistema de ejecución del sistema operativo, y
controlar el proceso de salida, es decir, la gestión de los resultados imprimibles, que
pueden enviarse a una impresora (local o remota) o bien pueden guardarse en cinta o
disco.
En general, un trabajo pasa por las siguientes fases: entrada, conversión, proceso, salida,
impresión (gestión de los resultados imprimibles) y borrado.
El subsistema de entrada de trabajos lleva a cabo todas las fases, excepto la de proceso.
Un nombre más adecuado para este componente del sistema operativo sería el de gestor
de entrada y salida de trabajos, sin embargo la expresión subsistema de entrada de
trabajos está muy difundida por ser la traducción de "Job Entry Subsystem" (JES), que es el
gestor de trabajos del sistema operativo MVS de IBM. En este sistema operativo, cada
instalación puede elegir entre JES2 o JES3 como subsistema de entrada de trabajos.
Los parámetros de inicialización del subsistema de entrada de trabajos proporcionan al
técnico de sistemas la posibilidad de definir las políticas de la instalación acerca del grado
de control que los usuarios pueden tener sobre sus trabajos. Por ejemplo, si en una
instalación se permite que los usuarios definan la clase de sus trabajos y su prioridad,
seguramente todos elegirán la máxima prioridad y la clase que les pueda beneficiar más.
El resultado sería la inexistencia de una clasificación de prioridades efectiva. Por esta
razón, aunque un usuario puede utilizar algunas opciones del lenguaje de control de
trabajos (JCL) para definir la prioridad y la clase del trabajo, los parámetros de
inicialización del subsistema de entrada de trabajos van a determinar si se admiten o se
rechazan las opciones del usuario.
Este mismo tipo de control basado en la validación de las especificaciones de los usuarios
y, en su caso, establecimiento de un valor por defecto, se aplican a muchas definiciones
del JCL. Por ejemplo, el subsistema de entrada de trabajos puede especificar los límites
máximos permitidos para los trabajos de una determinada clase, en cuanto a tiempo de
ejecución, cantidad de memoria o líneas de salida imprimible.
Las especificaciones del subsistema de entrada de trabajos pueden ser sustituidas por los
valores por defecto del lenguaje de control de trabajos, y éstos a su vez pueden ser
sustituidos por las opciones concretas que el usuario determine para su trabajo, pero la
autorización para sustituir valores por defecto o parámetros de inicialización siempre está
controlada por el técnico de sistemas.
La siguiente tabla detalla cada una de las fases por las que atraviesa un trabajo en su
ejecución:
Fase Actividades
El JES recibe los trabajos, que están en formato de texto y se ajustan a la sintaxis
del JCL. Estos trabajos están guardados normalmente en un fichero en disco. El
usuario puede mandar su ejecución (submit) al JES de diversas maneras, siendo la
Fase de entrada más usual mediante un comando del gestor de la sesión interactiva (el TSO en el
sistema operativo MVS), si se hace desde un videoterminal, o mediante un
comando del propio sistema operativo o del JES, si se hace desde la consola del
sistema.
El JES analiza las instrucciones del trabajo, sustituye las llamadas a procedimientos
por las instrucciones correspondientes, y convierte el texto obtenido a un formato
Fase de conversión
interno, y posteriormente lo almacena en un fichero de SPOOL (Simultaneous
Peripheral Operations OnLine).
En esta fase, el JES responde a las solicitudes que va realizando el sistema

Fase de proceso operativo (concretamente desde los iniciadores, en el caso de MVS) para que le
suministre trabajos para ser ejecutados. El JES selecciona un trabajo de los que
están en la cola de entrada, esperando para empezar a ejecutarse. A

£
continuación vamos a analizar cómo se lleva a cabo la planificación de trabajos

para el comienzo de su ejecución.
El JES se comunica con un iniciador para arrancar un trabajo de los que están en
espera. Los iniciadores son programas del sistema operativo que se encargan de
arrancar los trabajos. Hasta que los trabajos no están arrancados no pueden
competir para obtener recursos del sistema.
Los iniciadores pueden estar bajo el control del JES o del Gestor de la carga de
trabajo del sistema operativo, en inglés Workload Manager (WLM). Los iniciadores
del JES comienzan a funcionar cuando el operador de consola emite el comando
adecuado, o bien automáticamente cuando se arranca el propio JES. Estos
iniciadores seleccionan los trabajos en función de la clase que éstos tienen
asignada, ya que cada iniciador sólo puede seleccionar trabajos de
determinadas clases. Dentro de la misma clase, los trabajos se seleccionan en
función de su prioridad de selección. Por otra parte, los iniciadores del WLM
comienzan a funcionar o dejar de funcionar automáticamente dependiendo de
los siguientes aspectos: los objetivos de rendimiento, la importancia relativa que se
haya asignado a los trabajos por lotes, y la capacidad del sistema para procesar
más o menos trabajos.
Los iniciadores asignan los recursos que sean necesarios para ejecutar el primer
paso del trabajo y después dan el control al programa que el usuario haya
especificado en dicho primer paso.
Cuando todos los iniciadores están ocupados (los iniciadores sólo se liberan
cuando termina el trabajo que han planificado), el tiempo de respuesta de
algunos trabajos podría deteriorarse debido al tiempo de espera para comenzar
la ejecución. Para tratar de evitar estas situaciones, el JES utiliza el mecanismo de
"priority aging", mediante el cual los trabajos van aumentando su prioridad de
selección en función del tiempo que llevan en la cola de entrada de trabajos.
Para llevar a cabo la ejecución de los trabajos, es necesario que se establezca
una comunicación continua entre el JES y el sistema operativo propiamente
dicho. Esta comunicación permite que el sistema operativo pida servicios del JES,
como seleccionar un trabajo, procesar comandos, o abrir ficheros que residen en
el SPOOL. También el sistema operativo tiene que notificar al JES algunas
circunstancias como los mensajes que se van produciendo, y el final de un paso o
del trabajo.
En esta fase se gestionan todos los resultados imprimibles que haya producido un
trabajo durante su ejecución. Estos resultados son ficheros de salida que el usuario
ha especificado en el JCL que deben imprimirse, aunque no necesariamente en
una impresora, como veremos a continuación. También se pueden tratar como
resultados imprimibles los mensajes que haya emitido el sistema operativo con
Fase de salida
relación al trabajo durante su ejecución.
Cuando el trabajo termina, el JES analiza la clase de salida asignada a los
resultados imprimibles y las opciones especificadas para los dispositivos físicos (por
ejemplo, un formulario especial o un conjunto de caracteres determinado para la
impresora), agrupa dichos resultados para que estén juntos los que tengan las
mismas características, y los deja en la cola de salida.
Las impresoras del ordenador tienen asignada una o varias clases de salida. Para
que un resultado pueda imprimirse por una impresora determinada deben
coincidir la clase asignada a la impresora y la clase de salida del resultado. De
este modo se van seleccionando los resultados de la cola de salida.
Es necesario distinguir entre clase del trabajo y clase de salida. En el sistema
operativo MVS ambas clases se designan mediante letras, pero no tienen ninguna
relación. La clase del trabajo sirve para que los iniciadores lo seleccionen para
comenzar su ejecución. Sin embargo, la clase de salida se asigna
Fase de impresión independientemente a cada resultado, por tanto puede haber varias clases de
salida en el mismo trabajo (por ejemplo, un fichero de salida se imprime en una
impresora láser local y otro se imprime en una impresora remota) y estas clases de
salida sirven para indicar por qué impresora concreta o grupo de impresoras se
debe imprimir el resultado.
Por otra parte, existen productos software que permiten extraer resultados de la
cola de salida y escribirlos en ficheros en disco, en vez de enviarse a la impresora.
Estos productos actúan coordinados con el JES, de modo que se puede asignar
una clase de salida determinada para realizar este proceso de "impresora virtual".
Además, los comandos de JES permiten realizar este proceso manualmente, es

£
decir, existen comandos para pasar trabajos o resultados desde el SPOOL a un

fichero en disco o cinta, o desde un fichero en disco o cinta al SPOOL, si bien este
tipo de comandos se suele usar con la finalidad de guardar temporalmente la
información del SPOOL cuando se va a realizar un arranque en frío del JES, ya que
este tipo de arranque inicializa el SPOOL.
Cuando termina el proceso de salida e impresión, el JES libera todo el espacio del
Fase de borrado (purge) SPOOL que estaba asignado al trabajo, y emite un mensaje al operador indicando
esta circunstancia.
2.1.1.3.1 Mecanismos de Control del JES

Además de los comandos de consola del sistema operativo, existen comandos específicos
del JES. Con estos comandos se puede controlar la ejecución de los trabajos y el proceso
de los resultados, así como controlar los dispositivos que están asignados al JES, que son
normalmente impresoras, aunque antiguamente también se controlaban las lectoras de
fichas y las perforadoras.
La mayoría de las definiciones iniciales del JES también se pueden cambiar mediante
comandos de consola. Estos comandos los pueden emitir los operadores o los técnicos de
sistemas.
Por otra parte, existe la posibilidad de planificar la ejecución de algunos comandos a
determinadas horas o periódicamente cada cierto intervalo de tiempo. Estos comandos
automáticos se suelen emplear para visualizar regularmente algunos parámetros
importantes del sistema y para liberar a los operadores del trabajo rutinario más tedioso.
Otra manera de automatizar la operación del sistema es utilizar algún producto
especializado, que captura los mensajes que aparecen en la consola y emite, como
respuesta a determinados mensajes, los comandos que se le hayan especificado.

£
2.1.2 Control de Incidencias en Trabajos
2.1.2.1 Control de Entrada de Trabajo

Algunas opciones del JCL permiten que un trabajo entre en el JES, pero sin posibilidad de
empezar a ejecutarse hasta que el operador no lo libere mediante el comando
adecuado. En este caso se dice que el trabajo está en estado "hold" o "retenido".
Las posibles razones para dejar un trabajo retenido son las siguientes:
Que sea necesario esperar a que termine otro trabajo, porque utilizan el mismo recurso
(por ejemplo, un fichero que ambos trabajos deben actualizar en exclusiva), o bien
porque el trabajo retenido utiliza como entrada un fichero que se obtiene como
resultado de la ejecución del otro trabajo.
Que el ordenador tenga una carga excesiva en ese momento, lo cual hace
aconsejable esperar a que vayan terminando los trabajos que están en ejecución para
poder procesar nuevos trabajos.
Este proceso manual se puede agilizar empleando un planificador automático, que puede
controlar las relaciones entre trabajos en cuanto al orden de ejecución y en cuanto a los
recursos compartidos por varios trabajos. Asimismo, los planificadores automáticos
permiten predeterminar la hora de comienzo de cada trabajo, con lo que las situaciones
de sobrecarga del ordenador sólo se producen si hay trabajos no planificados o trabajos
que se retrasan en su ejecución.
No obstante, la utilización de un planificador automático es compatible con la gestión
manual de los trabajos retenidos, si todos los trabajos planificados entran
automáticamente en estado hold y se deja que los operadores de consola decidan qué
trabajos deben comenzar a ejecutarse en cada momento en función de la ocupación del
ordenador.
En cualquier caso, la forma habitual de controlar el número y tipo de trabajos que deben
estar en ejecución en cada momento es a través del número de iniciadores activos y las
clases de trabajos que se asignan a cada iniciador.
2.1.2.2 Asignación de Clases

Cada trabajo tiene asignada una clase, que se especifica mediante una letra y figura
como un parámetro del JCL. Por lo general, todos los trabajos que tengan las mismas
características tienen asignada la misma clase. Por ejemplo, se pueden separar los
trabajos según los siguientes criterios:
Trabajos que realizan muchas operaciones de entrada/salida.
Trabajos que utilizan mucho la CPU.
Trabajos que están en desarrollo.
Trabajos que utilizan determinado recurso.
De este modo, se pueden cumplir determinados requisitos, como por ejemplo: que se
ejecuten simultáneamente el mismo número de trabajos intensivos en entrada/salida que
de trabajos intensivos en CPU. Para realizar esto deber haber el mismo número de
iniciadores activos para la clase correspondiente a los trabajos intensivos en
entrada/salida que de iniciadores activos para la clase correspondiente a trabajos
intensivos en CPU.
El número de iniciadores activos y la clase o clases asignadas a cada iniciador se pueden
modificar dinámicamente mediante los correspondientes comandos de consola, por lo

£
que a lo largo del día suelen variar estos parámetros conforme varía el número y la clase
de trabajos que se procesan.
2.1.2.3 Prioridades de Selección y de Ejecución

Los trabajos de la misma clase se seleccionan para comenzar a ejecutarse según su
prioridad de selección, que es distinta de la prioridad de ejecución. Los trabajos que
tienen la misma prioridad de selección comienzan a ejecutarse según el orden de llegada.
La prioridad de selección la calcula el sistema operativo según el tiempo de ejecución
estimado y la cantidad de líneas imprimibles estimadas. Estas estimaciones se pueden
especificar en el propio JCL, o bien tomar valores por defecto, aunque en última instancia
puede que no sean aceptables debido a las opciones de instalación del JES, que ha
definido el técnico de sistemas.
La prioridad de ejecución (dispatching priority) de un trabajo va variando en función de
los recursos que va consumiendo, aunque algunos trabajos pueden tener una prioridad de
ejecución fija, especificada en el JCL. Estos trabajos con prioridad fija suelen ser utilidades
o módulos del propio sistema operativo.
2.1.2.4 Comunicación con el Operador

Los principales mensajes que aparecen en la consola del operador durante la ejecución
de un trabajo son los siguientes:
Indicación de la fase en la que se encuentra el trabajo: entrada, ejecución, salida,
impresión y borrado.
Indicación de haber excedido algún límite, como el número de líneas imprimibles o el
número de cintas de un fichero. Dependiendo de las opciones que estén vigentes, el
trabajo podría terminar automáticamente (con volcado de memoria o sin él) o bien
puede permitirse que continúe.
Solicitud de la intervención del operador. Por ejemplo, para montar una cinta o para
colocar un formulario especial en la impresora.
En algunas ocasiones el operador debe decidir la cancelación de un trabajo debido a
que el tiempo de ejecución es excesivo comparado con el tiempo de ejecución habitual
del trabajo, o bien debido a que se aprecian síntomas de que el programa que se está
ejecutando se encuentra dentro de un bucle infinito, es decir, ejecutando siempre la
misma secuencia de instrucciones.
En el primer caso, para decidir la cancelación es necesario conocer los siguientes datos:
Tiempo transcurrido desde el comienzo de la ejecución (elapsed time).
Recursos consumidos: tiempo de CPU empleado y número de operaciones de
entrada/salida realizadas.
Volumen de información que debe procesar. Por ejemplo, número de registros de los
ficheros de entrada.
Al comparar estos datos con los que se tengan de ejecuciones anteriores, se puede
decidir si el trabajo están consumiendo una cantidad de recursos exagerada y si, por
tanto, procede su cancelación.
En el caso de un posible bucle infinito, los síntomas suelen ser la aparición de mensajes que
indican que se ha sobrepasado el límite de líneas imprimibles, o un consumo muy alto de
CPU, o ambas cosas.

£
2.1.2.5 Ejecución Condicional

Algunos parámetros del JCL permiten condicionar la ejecución de uno o varios de los
pasos que componen un trabajo según el resultado de algún paso que se ha ejecutado
previamente. El resultado de un paso se expresa mediante un código de retorno que
genera el programa ejecutado, y en caso de producirse un error que impida que el
programa termine normalmente, en lugar de código de retorno tendrá como resultado un
código de error generado por el sistema operativo (que se denomina código de "AbEnd",
abreviatura de Abnormal End, en el sistema MVS).
El código de retorno es un código numérico que todos los programas (tanto los del sistema
como los de usuario) dejan como resultado, al finalizar, en un registro de la CPU.
Normalmente se establece un convenio para que este número indique si el programa ha
terminado correcta o incorrectamente. Por ejemplo, el cero suele significar que ha
terminado bien, los otros indican algún tipo de aviso y otros indican que ha ocurrido algún
error.
Cuando se produce un "abend" se termina la ejecución de todo el trabajo, salvo que se
indique como condición en el JCL que se desea ejecutar alguno o varios de los pasos que
quedaban por ejecutar en el trabajo.
Algunos trabajos especifican que se escriba un volcado de memoria (dump) cuando se
produzca algún error. Un dump consiste en copiar a un fichero el contenido de las áreas
de memoria pertenecientes al programa que se estaba ejecutando, en el momento en el
que se produce el error o se solicita el dump; ya que también se puede escribir un dump si
el programa del usuario llama al servicio correspondiente del sistema operativo. En
cualquier caso, en el JCL es necesario especificar el fichero donde se quiere obtener
dicho dump. Como los ficheros donde se guarda un dump suelen ser bastante grandes, se
suele obtener el dump en un fichero en disco, en una ubicación temporal, donde se
puede analizar la información, y posteriormente guardarlo en cinta o bien imprimir alguna
parte concreta que convenga analizar con detalle.
Hasta aquí se ha descrito la ejecución condicional de los pasos que componen un trabajo,
pero también es posible condicionar la ejecución de un trabajo en función del resultado
de alguno o de cualquiera de los pasos que componen otro trabajo que se ejecuta
previamente. Esta posibilidad la proporcionan algunos planificadores automáticos de
trabajos. Por ejemplo, el trabajo A2 se puede planificar para que se ejecute todos los días
a las 21:00 siempre que el trabajo A1 haya terminado con un código de retorno igual a
cero en todos sus pasos.
2.1.2.6 Rearranque de Trabajos

a. Rearranque por terminación anormal
Si un trabajo falla en alguno de sus pasos, puede volverse a ejecutar sin tener que
comenzar desde el principio, siempre que el sistema operativo proporcione alguno o
varios de los siguientes mecanismos:
Rearranque automático desde el comienzo del paso.
Rearranque automático desde el último checkpoint.
Rearranque diferido desde el comienzo del paso.
Rearranque diferido desde el último checkpoint.
Los rearranques automáticos los realiza el propio sistema, en cuanto se produce el fallo,
aunque pide al operador de consola que lo autorice o lo deniegue. Los rearranques
diferidos se llevan a cabo ejecutando de nuevo el trabajo, pero indicando en el JCL
que se trata de un rearranque, con especificación del paso desde el que debe
comenzar y/o del fichero de checkpoint que debe utilizar.

£
La técnica de checkpoint consiste en que el programa, durante su ejecución, realiza

llamadas periódicas (cada cierto tiempo o cada cierto número de registros
procesados) al sistema operativo, para que éste grabe en un fichero toda la
información relevante del proceso que está en marcha. De este modo, el sistema
operativo podrá reproducir la situación del programa cuando se solicite el rearranque.
b. Rearranque por fallo del sistema
Algunos sistemas operativos permiten que los trabajos que se estén ejecutando
cuando se produce un fallo del propio sistema operativo o bien cuando se para
ordenadamente el mismo, continúen ejecutándose en el próximo arranque. En el caso
de parada ordenada del sistema operativo, éste se encarga de guardar antes del
cierre la situación de los trabajos en ejecución. Sin embargo, para que un trabajo
pueda ser rearrancado después de un fallo del sistema, es necesario que en el JCL se
indique esta posibilidad, con lo cual el sistema operativo se encargará de guardar
periódicamente el estada del trabajo durante su ejecución.
c. Otros mecanismos de rearranque
En algunas ocasiones se puede establecer un mecanismo de rearranque directamente
controlado por la aplicación. El caso más simple es el de un programa que procesa un
fichero de entrada. Este programa debe escribir en un listado de salida, cada vez que
termina de procesar un registro, el número de orden del registro que acaba de
procesar. En caso de error, se puede rearrancar el programa volviendo a ejecutarlo,
pero indicando como parámetro del programa el número de registros que ya ha
procesado en la ejecución anterior. De este modo, el programa leerá dicho número
de registros sin procesarlos, y procesará solamente los siguientes.
Por último, cabe señalar que los productos que automatizan la operación o la
planificación de trabajos suelen incluir la posibilidad de gestionar el rearranque
automático. Por ejemplo, el planificador "Jobtrac" incluye el módulo "Runtrac" para
gestionar el rearranque. También el planificador "CA-Scheduler" realiza esta función a
través del módulo "CA-11".
2.2 Estructura y Elementos (Sentencias JCL)
2.2.1 Sintasis Básica de las sentencias JCL

//Name OPERATION OPERAND, OPERAND, OPERAND COMMENTS
Donde:
Name - Identifica la sentencia de manera que otras sentencias o el propio sistema
puedan hacer referencia a él.
Operation - Especifica el tipo de sentencia: JOB, EXEC, DD, o la especificado en el
comando OPERAND.
Operand - Contiene los parámetros separados por coma.
Comments - Opcional.
Reglas generales:
Debe empezar por // (exceto en la sentencia /*) en las columnas 1 y 2.
Solamente admite mayúsculas.
El campo NAME es opcional.
Debe empezar en la columna 3 si usado.

£
El campo OPERATION debe empezar antes de la columna 17.

El campo OPERATION es obligatorio.
Los campos OPERANDS deben terminar antes de la columna 72, y son separados por
comas.
Todos los campos, exceto los OPERANDS, deben estar separados por un espacio en
blanco.
2.2.1.1 Continuación de Sentencias

//LABEL OPERATION OPERAND, OPERAND,
// OPERAND,OPERAND,
// OPERAND,
// OPERAND
Cuando el tamaño total de la sentencia excede 71 columnas, se procede la partición de
la siguiente manera:
Se interrumpe la sentencia después deun OPERAND completo (incluyendo la coma
que le siegue) antes de la columna 72.
Se codifica // en las columnas 1 y 2 de la siguiente línea.
Se continúa la sentencia empezando entre las columnas 4 y 16.
2.2.1.2 Comentarios
//* ESTA ES UNA LÍNEA DE COMENTARIO
Un comentario contiene //* en las columnas de 1 a 3, podiendo las demás columnas ser
contener cualquier tipo de comentario.
2.2.2 Tipos de Sentencias

JOB - Identifica el inicio de un trabajo.
EXEC - Indica que trabajo debe ser hecho.
DD - Identifica que recursos son necesarios y sus ubicaciones.
2.2.2.1 Sentencia JOB

La sentencia JOB informa al SO el inicio del trabajo, suministra la información de cuenta de
usuario y los parámetros para empezar la ejecución. Cada trabajo debe comenzar con
una única sentencia //jobname JOB USER=identidad de usuario:
Jobname es un nombre descriptivo atribuído al trabajo por el usuario que servirá de
identificador en la impresióndel trabajo.
JOB indica el inicio del trabajo.
Userid está compuesta por 1 hasta 7 caracteres.
Otros operandos de la sentencia JOB son:
//jobname JOB USER=userid, TIME=m, MSGCLASS=class, NOTIFY=userid
USER - userid. Identidad del usuario para el sistema.
TIME - m Tiempo total del job en el mainframe.
MSGCLASS - class Clase de salida.

£
El parámetro MSGCLASS permite el usuario especificar la clase de salida del trabajo

adonde el SO debe escribir el registro del trabajo (job log) o las mensajes del JES. Si el
parámetro no es especificado, la clase J será usada (clase J - impresión el papel
agujereado de 8 1/2" por 11").
Las posibles clases de salida son:
o Papel contínuo.
o Salidas en terminales TSO.
o Clases C a Z de IBM.
NOTIFY - userid. Usuario receptor de los mensajes TSO enviado tras la finalización del
trabajo.
2.2.2.2 Sentencia EXEC

La sentencia EXEC (execute) identifica el programa o función que el trabajo es para
ejecución y como procesarlo.
//stepname EXEC procedure,REGION=####K o
//stepname EXEC PGM=program,REGION=####K
stepname - Parámetro opcional que identifica el paso.
EXEC - Indica el órden de invocar el programa o función.
procedure - Nombre de programa a ser ejecutado.
program - Nombre de la función a ser ejecutado.
REGION=####K - Cantidad de memoria disponible para el trabajo.
2.2.2.3 Sentencia de Definición de Datos (Data Definition - DD)

La sentencia DD debe ser incluida después de la sentencia EXEC para cada dataset
usado en el paso. La sentencia DD suministra el nombre del dataset, la unidad de E/S,
algunas veces un volumen específico en disco y la disposición final del dataset. El sistema
verifica que los recursos pueden ser alocados antes de dar inicio al trabajo.
2.2.2.3.1 Sentencia DD para Entrada de Datos

La entrada de datos por el operador es ta vez la forma más comun de suministrar datos al
sistemas. La codificación de datos de entrada se hace codificando:
//ddname DD *
.
.
.
/* (especifica el final de los datos)
SYSIN es frecuentemente usado como ddname para entrada de datos por el operador. La
secuencia /* marca el final de los datos.
2.2.2.3.2 Sentencia DD para ficheros de datos en Disco

//ddname DD UNIT=unittype,
// DSN=userid.name,
// DISP=(beginning,normal-end,abnormal-end),
// SPACE=(TRK,(primary,secondary,directory)),
// RECFM=xx,LRECL=yy,MGMTCLAS=retainx

£
ddname - De 1-8 caracteres. Debe empezar con una letra, $, @ o #.

DD - Identificador de la sentencia DD.
UNIT = unittype - Un dispositivo de salida: disk, tape, etc.
DSN=userid.name - Nombre del dataset de entrada de datos. Datasets pueden ser
temporales, cuando creados y borrados durante la ejecución del trabajo, y no-
temporales, cuando se retienen después del fin del trabajo. Se limitan a 44 caracteres
en total, ej. UGIBM.DATA
2.2.2.3.3 Sentencia DD para ficheros de datos en Cinta Magnética

//ddname DD UNIT=unittype,VOL=SER=unitname,
// DSN=filename,
// DISP=(beginning,normal-end,abnormal-end),
// DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zz,DEN=density),
// LABEL=(file#,labeltype,,mode)
UNIT=unittype - Un dispositivo de salida: disk, tape, etc.
VOL=SER=unitname - Este parámetro es necesario si el dataset debe ser guardado en
un volumen en cinta específico.
DSN=filename - Nombre del fichero en la cinta magnética. El nombre puede estar
compuesto de 1 a 17 caracteres en longitud.
2.2.2.3.4 Sentencia DD para Salida de Datos en impresora

El parámetro SYSOUT proporciona una forma conveniente de enrutar la salida de datos a
una impresora u otros dispositivos.
//ddname DD SYSOUT=class
SYSOUT=class - Define el dispositivo de salida de los datos de acuerdo con la clase
asignada. Las posibles clases de salida son:
o Papel contínuo.
o Salidas en terminales TSO.
o Clases C a Z de IBM.
2.2.3 Sentencias de Salida

La sentencia OUTPUT es usada para especificar opciones de procesamiento a seren
aplicadas al dataset de salida de datos. Estas opciones son usadas solamente cuando la
sentencia OUTPUT es explícita o implícitamente mencionadas en la sentencia DD.
//name OUTPUT FORMDEF=fdef,PAGEDEF=pdef,CHARS=ch,FORMS=form,
// COPIES=n,DEST=dest,DEFAULT=dd
name - Nombre (de 1a 8 caracteres) dado a la sentencia OUTPUT.
OUTPUT - Identificador de sentencia OUTPUT.
FORMDEF=fdef - Simplex o duplex.

£
PAGEDEF=pdef - Define los parámetros de configuración de las páginas de impresión.

CHARS=ch - Define el tipo y tamaño del fuente.
FORMS=form - Define el tipo de formulario: contínuo o agujereado.
COPIES=n - Número de copias de impresión.
DEST=dest - Impresora de salida de datos.
2.2.4 Sentencias JES3 de Control
2.2.4.1 Sentencia //*MAIN

La sentencia //*MAIN define los requisitos de procesamiento para el trabajo en cuestión:
la hora de ejecución, el número de lineas a procesar y el destino de impresión.
//*MAIN CLASS=x,LINES=y,ORG=UGAIBM1.org
CLASS=x - Clase de trabajo: fines de semana, noche, cualquier hora del día, etc.
LINES - Define el número máximo de líneas de datos a imprimir para este trabajo.
ORG=UGAIBM1.org - Especifica la impresora destino para impresión de datos.
2.2.4.2 Planificación de Trabajos

Muchos usuarios pueden ahora compartir los recursos de procesamiento, incluso sin la
conciencia de la existencia de los demás, gracias al surgimiento del TSO, un sistema
operativo basado en el reparto de tiempo (time sharing). Su objetivo es maximizar el uso
de los mainframes por parte de los usuarios, no la eficiencia de los ordenadores mísmos,
como se podría a principio pensar, y se basa en el concepto de la Planificación de
Trabajos (job schedulling): maximización de la disponibilidad de los recursos a los usuarios
por asignación de clases de ejecución:
Clase de trabajo Prioridad
4
BATCH
3
NITE 2
Todo trabajo puede ser programado para ejecución nocturna o en fines de semana a
través de la sentencia //*MAIN CLASS=NITE o //*MAIN CLASS=WEEKEND
La siguiente tabla relaciona las limitaciones de recurso impostas pela Planificación de
Trabajos:
Prioridad Tiempo de Region (K) Número de

CPU líneas
requerido estimadas
(segundos)
6 0-30 0-2048 0-5000
4 32-120 2049-3072 5001-10000

£
3 121-300 3073-4096 10001-40000
2 301+ 4097+ 40000+
2.2.4.3 Sentencia //*OPERATOR

La sentencia //*OPERATOR es primariamente usada para indicar la necesidad de avisar el
operador de que una cinta con características VRN, VSN and KEYWORD debe ser
montada para llevar a caboi la ejecución de un trabajo.
//*OPERATOR VRN=#9999 VSN=U9999 KEY=HELP
VRN - Identidad de la cinta en la librería de cintas.
VSN - El número de volumen serial asociado a una cinta magnética.
KEY - Contraseña asociada a la cinta por motivos de seguridad.
La sentencia //*Operator siegue una sentencia JOB o //*MAIN y siempre viene antes de la
sentencia EXEC. Para leer o escribir un archivo en cinta magnética, cada sentencia
//*Operator debe de ser referenciada por una sentencia DD

£

Tema III.II.9 Documática. Archivo electrónico de documentos.
Organización funcional de los sistemas documáticos.
Optimización de consultas y recuperación de la
información.
Índice
1.- DOCUMÁTICA.................................................................................................................................. 3
1.1 Concepto................................................................................................................................ 3
1.2 Sistemas de Gestión de Bases de Datos Documentales .................................................... 3
2.- ANÁLISIS DOCUMENTAL.................................................................................................................. 4
2.1 Fases del análisis documental.............................................................................................. 4
2.2 La indización........................................................................................................................... 4
2.2.1 Indización por asignación..............................................................................................................5
2.2.2 Indización por derivación o automática ....................................................................................5
2.2.2.1 Eliminación de palabras vacías.........................................................................................6
2.2.2.2 Lematización .........................................................................................................................6
2.2.2.3 Ponderación..........................................................................................................................6
2.2.3 Traducción a lenguaje documental............................................................................................6
2.2.3.1 El tesauro ................................................................................................................................7
3.- ARCHIVO ELECTRÓNICO DE DOCUMENTOS.................................................................................. 9
3.1 Tendencias tecnológicas ...................................................................................................... 9
3.2 Tendencias organizacionales ............................................................................................. 10
3.3 El archivo electrónico en las Administraciones Públicas................................................. 10
4.- ORGANIZACIÓN FUNCIONAL DE LOS SISTEMAS DOCUMÁTICOS.............................................. 11
4.1 Repositorio de contenidos................................................................................................... 11
4.2 Captura ................................................................................................................................. 11
4.3 Flujos de trabajo (Workflow) ............................................................................................... 11
4.4 Indexación............................................................................................................................ 12
4.5 Búsqueda .............................................................................................................................. 13
4.6 Control de versiones ............................................................................................................ 13

4.7 Colaboración ....................................................................................................................... 14
4.8 Seguridad/Confidencialidad/Accesos.............................................................................. 14
4.9 Gestión del ciclo de vida documental .............................................................................. 14
4.10 Almacenamiento ................................................................................................................. 14
4.11 Salida e impresión................................................................................................................ 15
5.- OPTIMIZACIÓN DE CONSULTAS Y RECUPERACIÓN DE LA INFORMACIÓN ................................ 16
5.1 El proceso de Recuperación de Información ................................................................... 16

5.1.1 Funciones de búsqueda...............................................................................................................17
5.1.2 Indización o Creación del índice ...............................................................................................18
5.1.3 Consultas .........................................................................................................................................18
5.2 Evaluación de un Sistema de Recuperación de Información......................................... 19
5.3 Modelos de recuperación de la información ................................................................... 19

5.3.1 Modelo booleano .........................................................................................................................20
5.3.2 Índices invertidos............................................................................................................................20
5.3.3 Modelo vectorial............................................................................................................................20
5.3.4 Modelo probabilístico ...................................................................................................................21
5.3.5 Sistemas de hojeo-ojeo ................................................................................................................21
5.3.6 Booleano extendido .....................................................................................................................21
5.3.7 Lógica Difusa ..................................................................................................................................21
5.3.8 Otros modelos ................................................................................................................................22
5.4 Motores de Recuperación de la Información ................................................................... 22

5.4.1 Motores de búsqueda ..................................................................................................................22
5.4.1.1 Rastreo de la red con Robots-Web.................................................................................23
5.4.1.2 Indización de páginas web con Robot-Web................................................................24
5.4.2 Directorios temáticos ....................................................................................................................25
5.4.2.1 FFA (Free For All)..................................................................................................................25
5.4.3 Sistemas mixtos ...............................................................................................................................25
5.4.4 Metabuscadores............................................................................................................................26
5.4.5 Herramientas comerciales ...........................................................................................................26

1.- Documática
1.1 Concepto
La Documentación Automática /Documática es la disciplina que se ocupa de la
investigación y aplicación de las Tecnologías de la Información en todos los ámbitos de las
Ciencias de la Documentación. El proceso electrónico de documentos se refiere al
tratamiento de información no estructurada (imágenes, texto, gráficos, etc) en forma
digital.
El material de trabajo incluye la información generada y requerida durante el proceso
documental en el marco de los sistemas de información, en un contexto que integra los
medios automáticos, el ser humano y las interacciones entre ambos. La información está
en formato digital (documentos digitales) o bien procede del escaneo de documentos
(documentos digitalizados).
La definición se extiende a todos aquellos dispositivos, sistemas y tareas dedicados a
conseguir la máxima eficacia en la generación, archivo, circulación y, en su caso,
eliminación de cualquier tipo de documento.
La Documentación Automática/Documática ofrece dos vertientes:
Una, la investigación y desarrollo de nuevas aplicaciones, en combinación con otras
ciencias como la Informática, las Ciencias Cognitivas o las Ciencias de la Organización y la
Gestión. El objetivo es obtener nuevas aplicaciones o herramientas informáticas para el
tratamiento y recuperación de la información, así como métodos para la implantación,
gestión y control de estas aplicaciones o herramientas dentro de diferentes tipos de
organizaciones.
Otra, la utilización práctica de las aplicaciones, esto es, aplicación de las herramientas al
entorno o contexto que se precise, de forma que se optimicen los procesos documentales
e informativos del mismo.
Ambas se encuentran relacionadas, ya que la investigación se beneficia y alimenta de las
experiencias obtenidas en la aplicación de las herramientas que desarrolla, y a su vez las
nuevas herramientas permiten mejorar y adecuar cada vez más los procesos
documentales que se desarrollan en las unidades de información, al mismo tiempo que
intervienen, en numerosas ocasiones, en los procesos de organización y gestión de las
mismas. La Documentación Automática/Documática se relaciona con la Ciencia de la
Documentación, con la Informática y con la Ciencia de la Información.
1.2 Sistemas de Gestión de Bases de Datos Documentales

Las bases de datos documentales son adecuadas para:
9 Información no estructurada (no dividida en campos)
9 Grandes volúmenes de información
9 Objeto de trabajo: documentos, números, imágenes
Un sistema de gestión de bases de datos documentales (SGBDD) es un software que
incluye funciones de almacenamiento, indexación, consulta y modificación de la
información documental.

Los métodos y algoritmos de construcción de índices distinguen unas bases documentales
de otras. La idea básica es conseguir la máxima rapidez en la indexación, la consulta y la
modificación a costa del mínimo espacio de almacenamiento.
2.- Análisis documental

Cuando los documentos entran en el sistema deben identificarse mediante una serie de
características (formales y de contenido) que proporcionan una vía para su posterior
recuperación. El análisis documental es la operación que consiste en seleccionar las ideas
informativamente relevantes de un documento a fin de expresar su contenido sin
ambigüedades para recuperar la información en él contenida.
2.1 Fases del análisis documental

En el análisis documental se distingue entre análisis formal y de contenido:
x El análisis formal (nivel de asiento) es aquél donde se determinan los identificadores o

elementos objetivos del documento: tipo, autor, título, editorial, fecha, número de
páginas, idioma original, etc. Se trata de un análisis externo del documento que extrae
aquellos datos que lo distinguen típicamente de los demás (descripción bibliográfica o
catalogación).
x El análisis de contenido es aquella operación intelectual o automática según la cual se

determina el significado general del documento y se identifican los elementos que lo
representan temáticamente. Es un análisis interno del documento; se ocupa del
mensaje identificándolo e informando sobre él mediante una descripción analítica o
temática que se fundamenta en la indización y la condensación. Ambas operaciones
son en principio conceptualmente independientes.
o La indización (nivel de descriptor o de indización) permitirá saber qué materia

es tratada por el documento analizado. Los productos de la indización son las
palabras clave, los índices de clasificación y los descriptores. En la indización se
trabaja generalmente con el lenguaje documental, que es un lenguaje artificial
donde se busca una mayor concreción.
o La condensación (nivel de resumen) indicará qué dice el documento. El

producto de la condensación es un resumen analítico del texto completo (en
inglés, Abstract). En la condensación se emplea el lenguaje natural, es decir,
aquél en el que está escrito el documento resumido.
2.2 La indización
La indización es el proceso de extraer los términos que muestran el contenido de un
documento, adecuándolos a un lenguaje natural o documental para su posterior
recuperación. Consta de dos fases: la extracción de conceptos o palabras clave, y la
traducción y clasificación usando un lenguaje documental.
Se entiende por término aquella palabra o expresión que se utiliza para representar un
concepto o noción. Los términos de indización proporcionan una vista lógica del
documento y pueden obtenerse por varios métodos:
x por asignación: mediante indización intelectual con utilización de un lenguaje
documental externo, como por ejemplo un tesauro
x por derivación: mediante indización automática

x estadístico: selecciona los términos más significativos analizando la frecuencia de
los términos existentes
x sintáctico: utiliza técnicas de análisis morfológico-sintáctico
La consulta debe pasar por el mismo proceso de indización que los documentos:
2.2.1 Indización por asignación

La indización por asignación, manual o intelectual es aquélla que se lleva a cabo por
equipos de expertos documentalistas y profesionales del campo temático cubierto por los
documentos. La norma internacional ISO/DIS 5963, y su equivalente española UNE 50-121-
91 de Documentación indican los métodos para el análisis de documentos, determinación
de su contenido y selección de los términos de indización, aplicables en el caso en que
tales operaciones se realicen manualmente. Tales términos pueden pertenecer al lenguaje
libre o natural (no estructurado), o proceder de un lenguaje documental, también
denominado lenguaje de indización (estructurado y con un vocabulario controlado), o ser
una combinación de ambos.
Hay que tener en cuenta que el lenguaje utilizado para indizar el documento deberá ser el
mismo que con posterioridad se utilice para formular la pregunta que permita recuperar su
información.
Cuando los términos forman parte de un lenguaje documental se les llama formalmente
descriptores. Cuando los términos de indización proceden del lenguaje libre o natural,
entonces se llaman identificadores.
2.2.2 Indización por derivación o automática

La indización automática es una técnica interdisciplinaria donde intervienen entre otras, la
Lingüística, la Informática, la Estadística y la Documentación. Durante los noventa se han
realizado investigaciones encaminadas a indizar de modo automático información
multimedia (imágenes y sonido).
En la actualidad, cuando la indización se efectúa de manera automática, generalmente
un documento se representa por el conjunto completo de palabras que lo componen, si
bien se intenta reducir tal conjunto mediante transformaciones u operaciones sobre el
texto tales como:
x la eliminación de espacios en blanco, acentos, etc
x la eliminación de las palabras vacías

x la identificación de grupos de nombres
x la lematización
2.2.2.1 Eliminación de palabras vacías

La lista de palabras vacías es una relación de términos considerados como valores no
indizables, usados para eliminar potenciales términos de indización. Los términos de una
lista vacía carecen de todo significado a la hora de recuperar información, como ejemplo
podemos tomar el determinante "la", que no posee ninguna funcionalidad a la hora de
recuperar documentos, ya que en todos los documentos de la base de datos aparecerá
este término de forma casi segura y no nos aporta nada del contenido del documento
almacenado. Así, cada término potencial de indización es comprobado previamente,
verificándose su presencia en la lista de palabras vacías y es descartado si se encuentra
en ella.
2.2.2.2 Lematización
Se reducen las palabras a su forma de raíz más común, de esta manera se fusionan
palabras relacionadas.
2.2.2.3 Ponderación
A los términos se les puede asignar un valor numérico basado por ejemplo en su
distribución estadística, o sea, la frecuencia con la que los términos aparecen en
documentos, colecciones de documentos, o en subconjuntos de colecciones de
documentos, tales como documentos considerados relevantes en una búsqueda o
interrogación.
2.2.3 Traducción a lenguaje documental

Los lenguajes documentales son instrumentos creados con el objeto de traducir la
información contenida en los documentos, haciéndola de este modo accesible y
recuperable por diferentes personas, sea cual fuere su estilo, modo de hablar o escribir. En
el lenguaje documental la información debe expresarse en el menor espacio posible y sin
ambigüedades, es por ello que se realiza una condensación y simplificación del lenguaje
natural, utilizando sólo una parte de los centenares de términos que conforman este
último.
El objetivo de estas normas de clasificación de los descriptores es producir los mínimos
índices de ruido (información irrelevante en la consulta) y los mínimos silencios
documentales (datos solicitados pero no obtenidos por distorsión del proceso).

Los lenguajes de búsqueda pueden ser lenguaje libre (Free Text) y lenguajes controlados.
En el lenguaje libre coexisten diferentes significados para un solo significante o diversos
significantes anónimos, en cambio el lenguaje documental ejerce un control léxico que
impide la utilización de distintos significantes libres para un mismo significado.
Un ejemplo de lenguajes controlados es un tesauro.
2.2.3.1 El tesauro
Desde el punto de vista de su estructura, el tesauro es un vocabulario controlado y
dinámico de términos que tienen entre sí relaciones semánticas y genéricas y que se
aplica a un campo particular del conocimiento. Desde el punto de vista funcional, un
tesauro es un instrumento de control de la terminología utilizado para trasladar en un
lenguaje más estricto (lenguaje documental) el lenguaje natural utilizado en los
documentos.
Así pues, el tesauro es un diccionario que muestra la equivalencia entre los términos del
lenguaje natural y los normalizados y preferentes del lenguaje documental. Dicha
ambivalencia se expresa en la recomendación ISO/DIS 5963, en la que dentro del tesauro
quedan incluidos los términos preferentes o descriptores, no preferentes o lead-in terms
(que son aquellos términos que no debemos asignar en la indización). Estas relaciones
explícitas facilitan las posibilidades de indización de los documentos y la formulación de las
preguntas por parte del usuario, dado que la acepción de los términos no admitidos remite
a los descriptores.
Se pueden aplicar distintos tesauros a la misma base de datos documental.
Descriptores
Se llama descriptores a los términos retenidos en un tesauro con objeto de llevar a cabo la
indización de documentos. Son términos o símbolos formalizados y homologados en un
tesauro y empleados para representar sin ambigüedad los conceptos retenidos en los
documentos y en las consultas documentales.
Relación entre descriptores
El tesauro o diccionario de descriptores es un conjunto predefinido de palabras clave que
muestran las siguientes relaciones:
1. Relaciones de equivalencia o preferencia
2. Relaciones Jerárquicas
3. Relaciones asociativas o de afinidad:
x Sinónimos y antónimos.
x Relación genética
x Conceptos coexistentes
x Causa y efecto
x Relaciones instrumentales
x Relaciones materiales
x Similitud
Presentación formal de palabras
Una vez se ha decidido retener un término dado en el tesauro, hay que verificar que éste
exprese lo más exactamente posible el sentido deseado:
Ortografía. Debe seguirse la norma más aceptada.

Forma sustantiva. El descriptor debe presentarse en sustantivo o equivalente.
Ejemplos: DEMOCRACIA por DEMOCRÁTICO, EJECUCIÓN por EJECUTAR
Número. La utilización de descriptores en singular o plural debe decidirse de
acuerdo con el idioma del tesauro. En inglés la tendencia es poner los plurales.
Adjetivos. Hay casos en que pueden utilizarse los adjetivos u otras formas no
sustantivadas. Ejemplo: SOCIAL, INTERNACIONAL,...
Abreviaturas y siglas. Evitarlas.
Puntuación. Reducir la utilización de signos de puntuación.

3.- Archivo electrónico de documentos
Los responsables de archivo de hoy tienen que plantearse cómo tratar documentos
dispuestos en los nuevos soportes y tienen que contar con especialistas informáticos para
desarrollar técnicas de manejo y preservación.
El asunto resulta complicado, ya que los nuevos documentos conviven en el archivo con
los documentos en soporte tradicional, y no sólo conviven al compartir un espacio físico
(primero una oficina y luego un archivo de depósito en la misma institución o fuera de ella)
sino que incluso conviven en el tiempo y en la función que cumplen. Es decir, en la
tramitación de un expediente puede darse el caso de que se generen documentos en
papel y documentos electrónicos. El archivero no deberá dar distinto tratamiento
archivístico a esos documentos basándose en la diferencia de los formatos. Al contrario,
deberá respetar siempre los principios que sustentan la archivística, y tratar a todos como
parte de un expediente.
De igual modo, puede ocurrir que una serie documental está compuesta por expedientes
en papel, expedientes en soporte electrónico y expedientes compuestos por documentos
en diferentes formatos; todos ellos son expedientes del mismo tipo, de la misma serie
documental, y como tal deben ser tratados en su ordenación lógica, no en la física, ya
que no es posible ordenar papeles y archivos electrónicos con un mismo criterio.
Por tanto, la gestión de los registros electrónicos no significa tener que crear nuevas teorías
archivísticas. Los principios de la archivística tradicional -valor probatorio e informativo de
los documentos, principio de procedencia, niveles de ordenación y descripción- se
mantienen en la práctica.
3.1 Tendencias tecnológicas

El sistema informático del archivo debe integrar todas las tareas que éste realiza:
adquisición del material que necesita y cuya compra dependa de su propio presupuesto
(ordenadores, mobiliario, material de oficina, soportes documentales...); control de la
documentación que alberga, de los distintos tipos de accesos al sistema que se otorgan,
de las consultas que se realizan a la base de datos, de los periodos de transferencia si los
hay; almacenamiento de los documentos; y difusión de información acerca del propio
funcionamiento del archivo (normas, información que recoge...) y de la documentación
de que dispone.
El sistema implantado en un archivo de documentos electrónicos deberá tener en cuenta
los avances de la tecnología y permitir volcar su información de una forma fácil y fiable a
otros soportes más novedosos y acordes con la tecnología que usan los creadores y las
necesidades de la organización.
Como último punto relativo a las tecnologías, diremos que se está haciendo cada vez más
imprescindible la interconectividad de los sistemas para intercambiar información, para lo
cual es preciso contar con estándares de comunicaciones que permitan enviar
información dentro de una misma organización o entre varias. Uno de los formatos
implantados es el EDI (Electronic Document Interchange). Por otra parte, el lenguaje XML
proporciona un estándar abierto de almacenaje, publicación e intercambio de
información electrónica, con independencia de la plataforma, el formato y las fuentes de
donde proceden los datos. XML permite dotar al documento de estructura para el
intercambio de información electrónica a través de internet.

3.2 Tendencias organizacionales
El uso de sistemas informáticos ha hecho cambiar el modo de trabajo en las
organizaciones: muchas tareas se realizan con el ordenador, incluso si se trabaja en
equipo o si un documento/expediente lo crean varias personas, ya que es posible transferir
la información de un ordenador a otro a través de la red de la institución. Además, esos
documentos a menudo se presentan en soporte electrónico a sus destinatarios, sin
necesidad de imprimir una o más copias en papel y almacenarlas también en soporte
informático. Por el momento se dan casos de duplicidad de información, ya que se
guarda en papel y en disco. La superposición que supone usar papel y soporte electrónico
en una misma organización está creando un caos de información tanto a la hora de
tratarla como de almacenarla en el archivo.
La introducción de los documentos electrónicos en las organizaciones y por tanto en sus
archivos ha originado un cambio en la política de la gestión de los documentos, que
afecta a diferentes aspectos dentro de las tareas del archivo. Es preciso establecer
políticas en cuanto a la facilitación de la gestión de los documentos para saber qué rol
debe asumir el archivo; en cuanto a la valoración para determinar qué criterios seguir; en
cuanto a la adquisición, para adoptar las estrategias más adecuadas en cada
circunstancia; en cuanto a la descripción, para emplear los formatos que mejor se
adaptan a la documentación y a las necesidades del archivo; en cuanto a la
preservación, para implantar las estrategias que mantengan mejor la integridad física e
intelectual de los documentos en el tiempo; y en cuanto a la difusión, el acceso y la
recuperación, para adoptar las estrategias que darán mejor esos servicios.
3.3 El archivo electrónico en las Administraciones Públicas

Dentro de las instituciones de cada país, los organismos que más cantidad de documentos
generan y reciben son las administraciones públicas, por lo que les ha resultado
fundamental aprovechar las ventajas que ofrece la informática en el desarrollo de las
tareas administrativas: procesadores de texto, hojas de cálculo, bases de datos,
estadísticas, etc., agilizan el trabajo diario y facilitan la gestión.
Aunque una gran parte de la documentación que se produce por medios automatizados
se imprime para trabajar con ella y almacenarla después, comienza a plantearse el
archivo electrónico como una forma habitual de almacenamiento de documentación
originada en soportes informáticos.
La Ley 30/92 de 26 de Noviembre, de Régimen Jurídico de las Administraciones Públicas y
del Procedimiento Administrativo Común regula algunos aspectos relacionados con el uso
de las nuevas tecnologías de la información en las administraciones públicas.
En su artículo 38 trata de la obligatoriedad de la informatización de los registros, para lo
cual se exige una intercomunicación entre los registros de las distintas administraciones
públicas, así como la compatibilidad informática de éstos y la posibilidad de transmitirse
telemáticamente los asientos que contienen. En el momento de aprobar la ley no fue
posible llevar a cabo las prescripciones de este artículo debido a incompatibilidades entre
los distintos sistemas informáticos usados en las administraciones públicas. Para cumplir con
la ley el Ministerio de Administraciones Públicas ha creado el sistema SICRES (Sistema de
Información Común de Registros de Entrada y Salida).

4.- Organización funcional de los sistemas documáticos
Los sistemas documentales son dinámicos y deben adaptarse a muy variadas necesidades
y procesos. A continuación se definen los elementos principales que deben componer
cada instalación.
4.1 Repositorio de contenidos

Es el almacén de los contenidos. No suele referirse al soporte físico, sino a la estructura de
hardware, de software y organizativa a la que deben acudir todas las solicitudes realizadas
al sistema documental.
La duplicidad de documentos y la disparidad de criterios para su ubicación son dos de los
mayores enemigos de cualquier sistema documático, así que los expertos recomiendan las
estructuras basadas en un único repositorio.
4.2 Captura
Todo sistema documental precisa herramientas que permitan incorporar documentos al
repositorio. Esta fase de captura debe integrar varios conceptos:
x Tecnologías del “document imaging” o del escaneado. La transformación de
documentación en papel a formato digital sigue siendo una necesidad para
muchísimas empresas. Las fuentes de información crecen y el sistema documental
de una empresa debe recogerlas todas y anticipar futuras demandas.
x Conversión es el término comúnmente utilizado para definir la transformación de un
documento de datos (procesador de textos, hoja de cálculo, etc.) en otro de
imagen no editable. Se garantiza así la disponibilidad sin disponer de la aplicación
que lo creó.
x Importación es el concepto contrario, y se refiere a la incorporación de los
documentos en su formato nativo al sistema documental, asegurando que éste
disponga de los visores necesarios o asociados a las aplicaciones de origen.
4.3 Flujos de trabajo (Workflow)

Sistema de enrutamiento de los documentos que debe asegurar su correcta circulación
por todos los procesos e individuos implicados en su generación, corrección, aprobación y
disposición final.
Los flujos documentales pueden basarse en procesos sencillísimos basados en aplicaciones
informáticas comunes o en programas muy básicos de enrutamiento, pero también
pueden llegar a ser complejos sistemas en los que entran en juego conceptos superiores
como el control de versiones, las firmas digitales, el control dinámico de accesos, el
acceso concurrente o múltiple, las herramientas de cooperación, etc.
En todos los casos, deben ser los flujos documentales los que se adapten a los procesos de
trabajo -y no al revés-, aunque es normal que éstos últimos se revisen más de una vez
durante la implantación de un sistema documental, por sencillo que sea.
Entre las prestaciones que debe satisfacer un flujo están:
x Planificación gráfica de rutas. Para “dibujar” de un modo visual los diferentes
recorridos de los documentos por el organigrama de la empresa.

x Rutas paralelas. No todos los documentos siguen el mismo proceso y las variaciones
pueden crecer y cambiar. El sistema debe soportar la máxima diversidad posible.
x Enrutamiento por reglas. Se deben automatizar todos los procesos posibles y eso
incluye la entrada de los documentos en los flujos, que puede discriminarse por
infinidad de criterios (autor, nombre, procedencia, palabras clave, códigos,
metadatos...).
x Control de estados: si varios usuarios tienen que realizar aportaciones a un mismo
documento, el sistema debe gestionar el acceso a éste, de modo que no se
solapen modificaciones ni se generen conflictos de múltiple concurrencia.
x Delegación. La ausencia de un responsable no tiene por qué detener el flujo. El
sistema debe observar la posibilidad de que el administrador introduzca órdenes
de delegación de funciones en otro usuario, pero asegurando que éstas quedan
reflejadas y son trazables.
x Firmas digitales. Siempre que el flujo de un documento exija diversas fases de
aprobación, el sistema de firmas digitales es imprescindible.
x Auditoría y trazabilidad. Todos los procesos realizados deben quedar registrados
para su cómputo, análisis y seguimiento.
4.4 Indexación
(No confundir con indización o creación del índice en recuperación de la información)
El objetivo de un sistema documental no es archivar documentos, sino permitir un acceso
rápido y certero a aquellos que se necesitan o que pueden aportar valor y conocimiento
a quien los busca.
Esta premisa da la medida de la importancia de los conceptos de indexación,
categorización y búsqueda, que tienen una estrechísima interrelación entre sí, aunque su
implementación será radicalmente diversa en virtud de las necesidades y procesos de
cada empresa.
La indexación es la capacidad del sistema para generar directorios ordenados de los ítems
(documentos) disponibles en el repositorio. Se trata de tener la capacidad de ordenar los
documentos o sus referencias bajo criterios diferentes y de forma jerarquizada para facilitar
su utilización efectiva.
Hay tres modos de indexación primarios, que también pueden ser combinados entre sí, y
existen poderosas herramientas informáticas que permiten la automatización de los
procesos de indexación.
Por campos. Se asigna a cada documento una ficha o etiqueta que lo define según uno o
varios criterios. Las búsquedas se realizan filtrando uno o más de esos criterios para afinar
los resultados entregados. Se trata, en definitiva, de asignar palabras clave a cada
categoría, y en la construcción de esa arquitectura de palabras clave debe alcanzarse un
equilibrio entre robustez y flexibilidad.
Por texto completo. Realizar las búsquedas sobre el conjunto del contenido del
documento tiene como ventajas la práctica eliminación de los costes de indexación y de
los errores generados en ese proceso, así como la facilidad y universalidad del uso. Por el
contrario, exige una cierta habilidad en la búsqueda y ningún sistema puede garantizar al
ciento por ciento la correspondencia absoluta entre los resultados entregados y la
intención real del solicitante. La indexación por texto exige la aplicación de un OCR
(sistema de reconocimiento de caracteres) para los documentos escaneados.
Por estructuras de directorios. Es la correlación en digital de un archivo convencional en
papel, con la ventaja evidente de permitir una mejor estructura jerárquica y lógica. Cada

carpeta/directorio contiene los documentos que le han sido atribuidos (que quedan
catalogados por su ubicación) y a su vez forma parte de un árbol jerarquizado de
directorios y subdirectorios. No permite errores en la ubicación de los ítems (un documento
que no puede ser encontrado es un documento que no existe) y hace posibles las
duplicidades, pero resulta absolutamente eficaz en entornos poco variables, nítidamente
categorizados y con rutinas de trabajo muy marcadas.
4.5 Búsqueda
Los requisitos que deben regir cualquier sistema de búsqueda son Rapidez, concordancia
y jerarquización. Lógicamente, la localización está directamente relacionada con la
estructura de indexación aplicada.
La rapidez depende en gran medida de la disponibilidad de hardware, de infraestructuras
de telecomunicaciones adecuadas, y también de la arquitectura interna del sistema.
La concordancia de los resultados obtenidos con la intención de la búsqueda
La jerarquización: las respuestas entregadas por el sistema a cualquier consulta han de
poder ordenarse por niveles de concordancia, para asegurar al usuario una rápida criba
de los documentos que realmente le interesan.
La homogeneidad respecto a las plataformas informáticas utilizadas por los usuarios.
En los procesos de búsqueda, y muy especialmente en los realizados por texto completo,
el sistema debe observar una serie de herramientas que ya empiezan a ser de uso común:
x Lógica Fuzzy (difusa). Bien por errores en el OCR, bien por problemas al teclear,
bien por cualquier otro motivo, una palabra aplicada en la búsqueda puede estar
presente con alguna variación en uno o más documentos. La lógica “fuzzy”
interpreta esas pequeñas variaciones y ofrece como buenos los resultados en los
que el nivel de variación es mínimo. Los sistemas más completos permiten incluso
regular ese nivel de variación o de tolerancia.
x Comodines. El más utilizado en todos los entornos informáticos es el asterisco. Su
inclusión en algún punto de la cadena de caracteres solicitados deja al sistema
libertad para sustituirlo por cualquier letra o dígito que aparezca. Por ejemplo,
delimitar una fecha como “19**” permitiría obtener todos los documentos entre
1900 y 1999.
x Operadores booleanos. Los principales son AND, OR y NOT, y permiten establecer
variables lógicas que delimiten la búsqueda. AND obliga a que se den los dos
términos comparados; OR hace que se publiquen los documentos que contienen
al menos uno de los dos términos; NOT establece la búsqueda sobre uno pero
suprimiendo todos los que contengan el segundo.
x Proximidad. Permite delimitar la cercanía entre dos términos dentro del documento,
para evitar que aparezcan documentos que contienen las palabras solicitadas
pero sin relación entre ellas.
4.6 Control de versiones

Cuando el repositorio de documentos opera como mero archivo, no existe ningún
problema de cotejo de versiones, pero los procesos de trabajo se han acelerado y los
ciclos de vida de los documentos son cada vez más cortos y menos estables. Muchos
documentos deben ser revisados continuamente, con añadidos, supresiones,
modificaciones y actualizaciones necesarias para que conserven su vigencia.
Entre las funciones de las estructuras documáticas modernas destaca crear las rutinas,
asegurar los permisos y garantizar la no duplicidad (salvo que voluntariamente se decida).

En muchos casos, además, se exige la conservación de las versiones anteriores de los
documentos, para mantener la trazabilidad sobre los cambios introducidos. En este
aspecto, los mecanismos de control de accesos a cada documento o las firmas
electrónicas constituyen una necesidad creciente en entornos no técnicos, donde son
largamente conocidos.
4.7 Colaboración
Directamente entroncado con el control de versiones está el uso cada vez mayor de las
opciones de colaboración que la informática y las redes de telecomunicaciones permiten.
Los procesos de trabajo tienden hacia el teletrabajo y la interacción entre departamentos.
Todo sistema documental debe adaptarse a los procesos naturales de la actividad de una
empresa, y si esos procesos son colaborativos, la estructura documática debe estar
preparada para ello. En estos casos hay que permitir múltiples accesos concurrentes a un
mismo documento, disponer de opciones de anotaciones, vincular el sistema documático
con el de mensajería interna y garantizar la disponibilidad remota por Internet.
4.8 Seguridad/Confidencialidad/Accesos
La primera exigencia en cuanto a seguridad es la referente a las incursiones no deseadas
dentro del sistema documático, aunque esa protección no dependa directamente de
éste.
Cuando se habla de sistemas documentales, seguridad viene a ser sinónimo de
confidencialidad, o de la estructura creada para mantener esa confidencialidad y
definirla documento a documento si es preciso. Los sistemas de privilegios (o permisos de
acceso) deben responder fiel y detalladamente a la estructura organizativa y de toma de
decisiones de la empresa. Hacer que todos los documentos estén disponibles para cada
uno de sus posibles usuarios pero que ninguno sea visto por quien no debería, es un desafío
que obliga a un esfuerzo durante la implementación del sistema y a mantener la tensión
en el día a día de la introducción de contenidos al sistema, aunque también en este
campo se pueden automatizar muchos procesos.
Los sistemas documentales digitales permiten cotas de seguridad muy superiores a las de
los archivos tradicionales y sin necesidad de encerrar bajo una misma llave los
documentos que son secretos, los que son confidenciales para algunos y los que un día
fueron confidenciales pero que ahora podrían ser útiles para muchos. El embargo sobre
documentos debe tener una caducidad programable.
4.9 Gestión del ciclo de vida documental

Desde su creación hasta su caducidad, archivo definitivo o destrucción, todo documento
atraviesa diferentes estados en su ciclo de vida, normalmente relacionados con la persona
o el departamento que lo está utilizando en cada momento. En algunos entornos,
mantener la trazabilidad de cada documento es determinante para que en todo
momento se pueda saber quién tiene el documento o qué procesos de su ciclo de vida ya
han sido superados.
4.10 Almacenamiento
Es todo un subsector dentro del campo de las tecnologías de la información. Las
tecnologías de almacenamiento evolucionan continuamente y son cada vez más seguras,
rápidas y capaces. En cualquier caso, la automatización de los procesos de
almacenamietno es imprescindible, igual que el uso de soportes WORM (Write Once Read
Many, o guardar una vez y leerlo muchas) para el archivo definitivo.

Aunque la capacidad de almacenamiento ya no es una limitación técnica, sigue siendo
necesario el cálculo aproximado de los recursos de memoria necesario. La fórmula simple
es multiplicar el número de usuarios, por el número medio de documentos que crean, por
el peso medio de esos documentos y por el número de días que permanecen en el
sistema; la cifra resultante debe multiplicarse por dos.
4.11 Salida e impresión

El sistema debe garantizar todas las opciones de salida de la información que puedan
requerirse, en el momento de implementarlo o en el futuro. Los formatos de archivo
escogidos deben ser estándares abiertos y universales, y los documentos deben responder
a los requisitos de interoperabilidad necesarios para ser entregados en pantalla, por e-mail,
por fax, como SMS, a través del PDA, en forma de mensaje de voz o de cualquier otra
manera.
Todos los estudios apuntan, sin embargo, a que la impresión en papel seguirá siendo
durante mucho tiempo la forma preferida para visualizar documentos, particularmente si
no son muy breves. El sistema y los formatos de documentos deben garantizar una
impresión rápida, fiel y libre de problemas.

5.- Optimización de consultas y recuperación de la información
La recuperación de información es el conjunto de tareas mediante las cuales el usuario
localiza y accede a los recursos de información que son pertinentes para la resolución del
problema planteado. En estas tareas desempeñan un papel fundamental los lenguajes
documentales, las técnicas de resumen, la descripción del objeto documental, etc. La
informatización de estas tareas se engloba dentro del campo de la Documentación
Automatizada o Informática Documental.
El objeto documental se ha organizado y representado, utilizando una serie de normas y
convenciones, en un soporte informático, mediante el diseño, creación y mantenimiento
de bases de datos. La siguiente fase lógica es la recuperación del contenido de las
mismas, siguiendo unos criterios de pertinencia. En el ámbito de la documentación
automatizada, la recuperación de información adoptará la forma del acceso, selección y
explotación de las bases de datos, utilizando diferentes técnicas.
Diferencias entre recuperación de datos (RD) y recuperación de información (RI)
1. En RD la entidad buscada es un registro mientras que en RI buscamos documentos.
2. En RD buscamos una correspondencia exacta entre la pregunta formulada y la
respuesta obtenida, comprobando si un determinado ítem está presente o no en
un fichero. En RI buscamos aquellos ítems que concuerdan parcialmente con la
necesidad de información, y entonces seleccionamos, entre éstos, los que mejor se
correspondan con la petición; es decir se seleccionan los que sean más relevantes.
3. El lenguaje de interrogación utilizado en RD es generalmente artificial, con una
sintaxis y vocabulario restringidos; se da una especificación completa de lo que se
busca. En RI es posible utilizar el lenguaje natural, aunque con excepciones.
Recuperación de datos Recuperación de información
Entidad buscada Registros Documentos
Correspondencia Aproximada/ Mejor

Exacta
pregunta/respuesta correspondencia (relevancia)
Lenguaje de interrogación SQL Natural/Artificial
5.1 El proceso de Recuperación de Información

Las fases de la cadena de recuperación de información se reducen a cuatro:
-Búsqueda de documentos en la red.
-Indización de los documentos encontrados.
-Consultas de los usuarios por medio de la interfaz de interrogación.
-Presentación de los resultados de la búsqueda.

5.1.1 Funciones de búsqueda
Las capacidades de búsqueda propias de los sistemas de recuperación de información
automáticos incluyen: operadores booleanos, operadores de proximidad, operadores de
comparación, truncamiento y máscaras, limitación de las búsquedas a determinados
campos y recuperación de una cierta parte de un documento o un tipo de archivo.
Operadores booleanos
El álgebra de Boole se utiliza en la recuperación de información automática para
establecer las condiciones de búsqueda en lo que se refiere a la combinación de los
términos dentro de los documentos. Los operadores booleanos son tres: intersección, unión
y exclusión.
La intersección sirve para controlar que los documentos recuperados van a contener
todos los términos de búsqueda introducidos en la ecuación; se identifica con la
conjunción copulativa Y, que equivale a la operación de la multiplicación. Tiene como
consecuencia un menor número de resultados que si se usa el operador de unión, ya que
deben aparecer en cada documento todas las palabras para ser recuperados.
La unión equivale a la operación de la suma, y se identifica con la conjunción disyuntiva
O. La unión de dos o más términos o secuencias en una ecuación de búsqueda supone la
recuperación tanto de documentos que contengan sólo una de las condiciones como de
los que contengan ambas. Su utilización amplía el número de resultados en relación a lo
que ocurre con el operador de intersección.
La exclusión o negación sirve para indicar que determinados términos no deben aparecer
en ninguno de los documentos recuperados. Matemáticamente equivale a la resta; se
identifica con el adverbio de negación NO.
En una ecuación de búsqueda se pueden combinar los tres operadores o agrupar varios
términos con un operador frente a otros términos utilizando paréntesis. Por ejemplo, si
queremos encontrar información de las películas dirigidas por Fernando Trueba en las que
actúen Jorge Sanz, Gabino Diego o Maribel Verdú, pero no Ariadna Gil, introduciremos la
secuencia siguiente:
Fernando Trueba Y (Jorge Sanz O Gabino Diego O Maribel Verdú) NO Ariadna Gil

Operadores de presencia y ausencia
Poseen una función similar pero no igual a la de los booleanos. La presencia indica la
obligatoriedad de que un término aparezca en todos los documentos recuperados; la
manera más habitual de indicar esta condición es preceder al término afectado del signo
de adición (+). La ausencia significa que el término en cuestión no deberá estar incluido
en ninguno de los documentos recuperados; se indica con el signo de la sustracción
precediendo al término. Por ejemplo, si nos interesa encontrar información sobre la
educación fuera de Europa, deberemos introducir:
+educación –Europa
Operadores de proximidad
Sirven para limitar el espacio que se quiere que haya entre dos términos introducidos. Se
pueden buscar vocablos que estén juntos, separados por varias palabras o caracteres,
que se encuentren en una misma frase o párrafo, y además especificar si se debe respetar
el orden en el que se han introducido los términos, o no tiene que tenerse en cuenta. Estos
operadores, habituales en los sistemas de recuperación de información documentales, no
se han implementado de forma generalizada en los motores, excepto en las opciones de
búsqueda de frases. La mayoría de los motores permiten indicar si la secuencia de
búsqueda introducida debe considerarse como una frase; la frase es un tipo de
proximidad. Concretamente se trata de la adyacencia, puesto que los términos deben
aparecer seguidos, y además respetando el orden en el que se introdujeron.
Operadores de comparación
Se usan en los motores para indicar al sistema de búsqueda que los documentos
recuperados deben contener una fecha anterior, igual o posterior a la indicada; se utilizan
para restringir las búsquedas por fecha de creación o última actualización de las páginas
web.
Truncamiento
El truncamiento es la suplantación de una parte de un término por un comodín que puede
ser sustituido por uno o varios caracteres. Esta opción, habitual en la mayoría de los
sistemas de recuperación de información tradicionales, es fácil encontrarla en la mayoría
de los motores de búsqueda.
5.1.2 Indización o Creación del índice

El índice es una estructura de datos, generalmente un fichero inverso, que recoge la
representación del contenido de los documentos (generalmente, términos de indización) y
la organiza adecuadamente para permitir una búsqueda rápida sobre un gran volumen
de documentos.
Previamente habrá que definir la base de datos textual, especificando de qué
documentos constará, efectuar el análisis documental y decidir qué modelo de texto se
utilizará (estructura y elementos que se podrán recuperar).
5.1.3 Consultas
Las consultas en un sistema de Recuperación de Información SRI se realizan en una serie
de pasos:
¾ Definición de las necesidades de información del usuario.
¾ Selección y ordenación de las fuentes a utilizar.

¾ Traslación de las necesidades informativas del usuario al lenguaje documental
propio de la fuente que se va a utilizar. Si la fuente no precisa de vocabulario
controlado habrá que afinar la terminología.
¾ Traducción de la expresión en lenguaje documental al lenguaje de consulta de
cada sistema (ecuación de búsqueda). En algunos casos será introducir
simplemente un conjunto de 'palabras-clave', en otros casos pueden ser una
complicada combinación de operadores (booleanos, de proximidad, de
existencia, de exactitud), palabras-clave y paréntesis. Algunos sistemas facilitan la
expresión de la consulta mediante el uso de formularios combinados con menús
desplegables, otros permiten tomar un documento como ejemplo de consulta, y
ciertos sistemas incluyen la posibilidad de realizar una búsqueda expresada en
lenguaje natural.
¾ Ejecución de la consulta (sobre la ecuación de búsqueda se realizarán las mismas
operaciones que el sistema haya realizado sobre los textos). El sistema consultará el
índice y ordenará los documentos por relevancia para presentarlos al usuario.
¾ Exploración de los resultados para analizar su pertinencia o no a la cuestión
planteada.
¾ Si los resultados no son pertinentes o son demasiado exhaustivos, replanteamiento
de las expresiones utilizadas.
5.2 Evaluación de un Sistema de Recuperación de Información

Los parámetros para valorar la calidad de una búsqueda son la precisión y la
exhaustividad.
Índice de precisión IP
Es el número de referencias correctas (documentos relevantes recuperados) dividido por el
número total de documentos relevantes.
Índice de retorno IR
Este índice también se denomina de llamada o exhaustividad. Es el número de referencias
obtenidas en la consulta (documentos relevantes recuperados) dividido por el número
total de referencias existentes (documentos relevantes en la colección).
Es prácticamente imposible determinar qué documentos relevantes de la colección no
han sido recuperados, por lo que se suele calcular la exhaustividad de un sistema en base
a técnicas estadísticas y de muestreo.
Cuando el número de resultados devuelto es excesivo, se recurre a técnicas de restricción,
introduciendo términos más específicos, desechando términos generales o limitando los
truncamientos. Si sucede lo opuesto, es decir, el número de resultados es muy reducido, se
realiza lo contrario: se utilizan términos más generales (incluyendo derivados), se limitan los
operadores más restrictivos, etc.
5.3 Modelos de recuperación de la información

Los modelos de recuperación más comunes son los siguientes:
1. Modelo booleano
2. Indices invertidos
3. Modelo vectorial
4. Modelo probabilística

5. Lógica difusa
6. Sistemas de hipertexto e hipermedia
5.3.1 Modelo booleano

Dentro de un sistema booleano, los documentos se encuentran representados por
conjuntos de palabras clave, generalmente almacenadas en un fichero inverso. Un fichero
inverso es una lista de palabras clave y de identificadores de los documentos en los que
éstas aparecen. Las búsquedas booleanas consisten en expresiones de palabras claves
conectadas con algún/nos operador/es lógico/os (AND, OR y NOT).
Si bien se han criticado estos sistemas, ha resultado complicado aumentar su efectividad
en la recuperación de información. Algunas de sus limitaciones son:
x Excesivamente estricto con los operadores. Consideremos la consulta A and B and C and
D and E. Un documento indizado por todos menos uno de los anteriores términos no sería
recuperado como respuesta a tal consulta, aunque quizás el usuario estuviera interesado
en él. De forma similar, para una consulta de la forma A or B or C or D or E, un documento
indizado por alguno de esos términos sería considerado igualmente importante que uno
indizado por varios o todos ellos.
x El modelo booleano puro no puede ordenar los resultados por relevancia. Durante el
proceso de indización se decide si un documento es relevante respecto a un término de
indización dado, en función de si ese término está presente en el documento o no. Por
tanto da lo mismo que un documento contenga una o muchas veces las palabras de la
consulta. No permite capturar la incertidumbre presente en la toma de decisiones de
indización.
x Tampoco permite asignar pesos a los términos de la consulta de manera que el usuario
pueda indicar si la presencia o ausencia de un determinado término es más importante
que la de otro.
5.3.2 Índices invertidos

Para minimizar el tiempo de búsqueda del sistema booleano apareció el método del
índice invertido. Durante la catalogación se genera un fichero inverso donde aparece,
para cada término, una lista de todos los documentos en los que aparece. El proceso de
recuperación se acelera así de forma sustancial.
Los SGBDD se basan en el método del fichero inverso para localizar los documentos
asociados a una búsqueda concreta. Durante la catalogación se genera un fichero
inverso, que es una lista de términos y los documentos en que aparecen esos términos. De
esta forma la recuperación se acelera.
5.3.3 Modelo vectorial

En el modelo vectorial los documentos se representan como vectores cuyos elementos son
las frecuencias de todas las claves de dichos textos.
Esto es, se almacena con cada término el número de ocurrencias en cada documento. Si
un término aparece mucho en un documento, se supone que ese término es importante
en ese documento, pero si aparece en muchos documentos eso significa que ese término
no es útil para discriminar un documento de otros. Normalizando por la cantidad de
términos que tiene un documento se da más importancia a la aparición de ese término en
documentos cortos.

Representados así, los documentos pueden situarse en un espacio vectorial de n
dimensiones, es decir, con tantas dimensiones como elementos tenga el vector.
Matemáticamente hace tiempo que se trabaja con espacios de n dimensiones, dando a
n un valor superior a tres. Situado en ese espacio vectorial, cada documento cae
entonces en un lugar determinado por sus coordenadas, al igual que en un espacio de
tres dimensiones cada objeto queda bien ubicado si especificamos sus tres coordenadas
espaciales.
Se crean así grupos de documentos que quedan próximos entre ellos a causa de las
características de sus vectores. Estos grupos o clusters están formados, en teoría, por
documentos similares, es decir, por grupos de documentos que son relevantes para la
misma clase de problemas de información. Grupos de clusters pueden organizarse, a su
vez, en torno a un centroide, que es un documento representativo de las propiedades
medias de los documentos del cluster. En una base de datos documental organizada de
esta manera, resulta muy rápido calcular qué centroide se parece más a una pregunta, y
es muy rápida también la ordenación por relevancia, ya que, de forma natural, los
documentos ya están agrupados por su grado de semejanza.
En la fase de interrogación, cuando se formula una pregunta, también se la deja caer en
este espacio vectorial, y así, aquellos documentos que queden más próximos a ella serán,
en teoría, los más relevantes.
5.3.4 Modelo probabilístico

Se ha tratado de mejorar el rendimiento de los SRI por medio del uso de la información
procedente de la distribución estadística de los términos, en tanto que la frecuencia de
aparición de un término en un documento o conjunto de documentos podría considerarse
un dato relevante a la hora de establecer una interrogación a la base de datos. Por medio
del uso de modelos probabilísticos y de las distribuciones de frecuencia de los términos de
la base de datos, es posible asignar una probabilidad de importancia (un peso) a cada
documento dentro de un conjunto de documentos recuperados para ser ordenados
posteriormente según un cierto orden de importancia (pertinencia).
5.3.5 Sistemas de hojeo-ojeo

La consulta se basa en el uso de vínculos para saltar de unos documentos a otros,
haciendo ojeadas de selección buscando señaladores, tal como se haría en el índice de
un libro. Permite una integración con los sistemas hipertexto y multimedia.
5.3.6 Booleano extendido

Este modelo conceptual permite que un documento tenga asociado un peso para cada
término de indización. Este peso indica la medida del grado en que el documento se
caracteriza por tal término. Los pesos toman valor en el rango [0,1]. Para recuperar
documentos relevantes en una determinada consulta, hay que calcular la similitud
consulta-documento.
5.3.7 Lógica Difusa

Es una extensión al modelo booleano. Mediante la lógica difusa se cuantifica el grado de
importancia relativa de las palabras clave, y los documentos se clasifican de acuerdo a la
relevancia estimada de estas claves. El índice de precisión aumenta respecto al método
booleano, e igualmente aumenta el índice de retorno.

5.3.8 Otros modelos
Existen otros modelos que se han creado como extensión de los anteriores pero que son
muy costosos de implementar y no siempre mejoran sustancialmente los clásicos:
x Extensiones al modelo vectorial
o Vectorial generalizado
o LSI: Latent Semantic Indexing
o Redes neuronales
x Extensiones al modelo probabilístico
o Redes bayesianas
o Redes de Inferencia Bayesiana
5.4 Motores de Recuperación de la Información

Los últimos años se han caracterizado por la velocidad en la producción de documentos
(el fenómeno conocido como explosión de la información), y una gran parte de ellos se
han puesto en las redes de telecomunicaciones.
El desarrollo de herramientas documentales pretende hacer posible una recuperación
rápida, efectiva y eficiente de la información. Los sistemas ideados para la
documentación en soporte papel tuvieron que adecuarse a las imposiciones de los
soportes magnético y óptico; después, con la aparición de internet, esos mismos sistemas
se han traspasado a las tecnologías de la telemática.
La estructura jerárquica de acceso a la información que ofrecía gopher y las técnicas
documentales de Wais quedaron atrás cuando se impuso la flexibilidad del protocolo http
y del lenguaje html de las páginas web. En poco tiempo, casi toda la información
disponible en la red se ha volcado a la web. Son muchos millones de documentos los que
se encuentran accesibles mediante este sistema de almacenamiento de información, y
muchas las herramientas que existen para facilitar el acceso a ellos: directorios de
empresas, localizadores de direcciones de correo electrónico..., pero fundamentalmente
son los buscadores y los directorios las herramientas capaces de localizar información
acerca de un asunto propuesto por el usuario.
Existen tres tipos de buscadores:
x Motores de búsqueda, o buscadores propiamente dichos.
x Directorios temáticos, Catálogos que agrupan sus enlaces por categorías
x Sistemas Mixtos tienen un directorio, además de su motor de búsqueda.
x Otros motores buscadores.
La elección entre motores y directorios, y dentro de cada grupo la inclinación hacia
algunos en concreto, debe hacerse conociendo lo que podemos esperar de ellos.
Veamos qué tipo de recurso elegir en cada momento y qué posibilidades nos ofrecen
algunos de los sistemas de recuperación de información existentes actualmente en
internet.
5.4.1 Motores de búsqueda

Los motores de búsqueda son herramientas dirigidas a la recuperación de información
disponible en internet. Básicamente, un buscador se compone de:

1. un robot que rastrea las páginas de la red en busca de novedades y las indiza
2. una base de datos donde se almacena una breve referencia de la información
indizada y su dirección electrónica
3. una interfaz que permite al usuario interrogar al sistema y recibir los resultados
obtenidos al explorar la base de datos
Con un motor de búsqueda, el usuario podrá señalar con mayor exactitud las consultas
utilizando las opciones propias de un sistema de recuperación de información o base de
datos documental, y además se realizará la consulta en casi todo el web, o incluso en
otras partes de la Red. Si la ecuación de búsqueda es correcta, en la mayoría de las
ocasiones el número de documentos recuperados es excesivo. Afortunadamente,
muchos motores poseen la capacidad de ordenar los resultados según la relevancia con
respecto a la consulta realizada, lo que ayuda al usuario a seleccionar los documentos
que va a leer en primer lugar. Una mala elección de los términos de búsqueda o una
errónea combinación de éstos tendrá como consecuencia un resultado inadecuado a la
intención del usuario.
Los Spiders requieren muchos recursos para su funcionamiento. Recorren las páginas
recopilando información sobre los contenidos de las páginas, principalmente el texto que
en ellas aparece. Cuando buscamos una información en los motores, ellos consultan su
base de datos, con la información que han recogido de las páginas, y nos la presentan
clasificados por su relevancia. De las webs, los buscadores pueden almacenar desde la
página de entrada, a todas las páginas de la web. Depende de los gustos del buscador, y
la consideración de importancia que tenga la web para ellos.
Cada cierto tiempo, los motores revisan las webs, para actualizar los contenidos de su
base de datos. Es frecuente que los resultados de la búsqueda no estén actualizados, de
forma que la información o la página no exista.
La relevancia u orden de presentación de los resultados de la consulta, viene determinada
por diversos factores que dependen de cada buscador. Sería demasiado prolijo tratar lo
que entienden los motores por relevancia, pero vamos a enumerar algunos factores:
x El tráfico que soporta la página
x El tipo de portal web
x La información que contienen las páginas
x Si los dueños de la página pagan al buscador
Esta última sirve para tener una mayor visibilidad de nuestra página web en los resultados
de la búsqueda. Es decir, si les pagamos hacen aparecer nuestro enlace en las primeras
páginas de resultados.
Ejemplos de Spiders: Google, Altavista, Hotbot, Lycos
5.4.1.1 Rastreo de la red con Robots-Web

Los buscadores poseen unos programas conocidos con los nombres de robots, spiders,
wanderers, crawlers, worms..., denominaciones que hacen alusión a su forma de trabajo.
Se trata de software que, a partir de unas determinadas páginas web indicadas por sus
responsables, recorre la red yendo de enlace en enlace y recogiendo todos aquellos
documentos que encuentra a su paso.
Los robots visitan las páginas que les permiten hacerlo; para preservar unas determinadas
páginas web de un servidor -o todas ellas- de la visita de algún robot en concreto o de
todos los posibles robots, se ha desarrollado un protocolo de exclusión de robots X en el
que se normaliza la creación de ficheros /robots.txt. Otra forma de evitar que una página
sea visitada, o tan sólo no sea indizada, es indicarlo por medio de etiquetas meta

introduciendo como nombre de la etiqueta (metaname) el término robots y como
contenido (content) la especificación nofollow para que el robot no la lea, o noindex para
que no la indice.
Cada vez que un robot llega a una página comprueba si la había visitado con
anterioridad o si es nueva para él. Si ya la había recogido, se asegurará de que no haya
sufrido modificaciones y, en el caso de que sí existan, actualizará la información que
almacenaba sobre ella. Si es la primera vez que accede a esa página, tomará los datos
de localización y la indizará. También puede ocurrir que páginas que tenía recogidas
hayan dejado de estar disponibles en la red o hayan cambiado de servidor; todo esto será
hecho notar por el robot, que automáticamente actualizará la base de datos. Desde
cada página visitada el robot tiene acceso a otras a través de los nodos que encuentra
en ellas; unos robots rastrean los enlaces que proporciona la página principal, otros
acuden también a los que aparecen en las páginas referenciadas por las principales, y los
hay que descienden incluso hasta un tercer nivel de rastreo.
5.4.1.2 Indización de páginas web con Robot-Web

Hasta ahora hemos visto cómo el robot recorre las páginas web (u otro tipo de información
disponible en internet), pero no cómo esas páginas se disponen para ser recuperadas por
el usuario en el momento en que pueda necesitarlas, esto es, qué métodos utilizan los
motores para analizar el contenido de los documentos.
Podemos atrevernos a decir que realizan una indización automática de los documentos
electrónicos a pesar de que todavía no han explotado todas las técnicas en la mayoría de
los motores. El sistema más habitual consiste en recoger el texto completo de cada página
encontrada y volcar cada palabra en el fichero invertido de la base de datos; así, cada
palabra tendrá una sola entrada en el fichero acompañada por los datos de ubicación
de los documentos en los que se encuentra.
Desde el punto de vista informático, esta técnica es la más sencilla de realizar para un
ordenador, pero el tamaño de la base de datos aumenta de una forma
desproporcionada y, además, al recuperar páginas completas se carga mucho el tráfico
de la red.
Desde el punto de vista documental, las técnicas de frecuencia de aparición de términos
en los documentos como revelación de su contenido resultan insuficientes, y se tiende
hacia una búsqueda que tenga en cuenta el significado de las palabras y expresiones y
las imprecisiones del lenguaje natural. El recuento estadístico de los términos es algo más
elaborado si se tiene en cuenta también la frecuencia con que aparecen esos términos en
la totalidad de la base de datos. Es decir, a un término que aparezca con gran frecuencia
en un documento pero también muchas veces en otros documentos se le asignará menos
peso que a otro término que aparezca con la misma frecuencia en el documento pero
que apenas esté en el resto de los documentos de la base de datos.
En estos recuentos es conveniente que el sistema disponga de una lista de palabras vacías
o antidiccionario, pero en el ámbito de internet, por ser de carácter universal, se complica
demasiado por la pluralidad de idiomas que alberga, ya que un término vacío de
significado semántico en una lengua puede tenerlo en otra.
Dentro de la técnica de frecuencia de aparición de los términos, algunos motores han
ideado métodos que afinan la indización automática, como son la ponderación de las
palabras que se encuentran en determinadas partes de los documentos como el título, las
cabeceras principales y los primeros párrafos, ya que el contenido fundamental suele estar
concentrado en esos puntos. Los robots distinguen esa información porque leen las
etiquetas del lenguaje del web, el html. Un ejemplo de motor que indiza de esta manera
es Lycos; este buscador realiza la indización en texto completo, pero da una mayor
importancia a los términos que se encuentren en el título, en la dirección electrónica del

documento, en las cabeceras, en los enlaces a otros documentos y en las primeras veinte
líneas.
Pero de todos los métodos que se están usando, el que mejor resultado ofrece con menor
gasto de recursos por parte de los motores es el que recupera la información de contenido
de las etiquetas meta. Se trata de unas etiquetas html que ofrecen información acerca del
propio documento, tanto de tipo formal como de contenido. Por el momento no está
regulado su uso y no todas las páginas disponen de ellas, aunque cada vez son más las
que incluyen las destinadas al resumen y a los descriptores. Los autores de las páginas son
los responsables de utilizar las metaetiquetas en sus documentos. Los motores son capaces
de reconocer las etiquetas html, y por tanto también las meta, pero no todos han
implementado este sistema de análisis de contenido de los documentos de la red. Entre los
primeros que recurrieron a las etiquetas meta para recuperar información en lugar de
recorrer las páginas íntegramente se encuentran AltaVista y OpenText Index, pero cada
vez son más los motores que hacen uso de estas etiquetas para recuperar información y
para presentar los resultados a los usuarios.
5.4.2 Directorios temáticos

Cuando la herramienta de búsqueda de información elegida es un directorio temático, el
usuario no necesita formular con términos su consulta, sino que es suficiente que
seleccione los temas más afines con sus necesidades. Este sistema asegura que todos los
documentos recuperados van a tratar efectivamente del tema en el que se han
clasificado, pero probablemente se hayan perdido muchos otros que no han sido
seleccionados por los responsables del directorio.
Los directorios son motores buscadores completamente distintos a los spiders. Los
algoritmos son mucho más sencillos, presentando la información sobre las webs registradas
como una colección de directorios. No recorren las webs ni almacenan sus contenidos.
Solo registran algunos de los datos de una página. Por ejemplo, guardan el título y la
descripción de la web que se introduzcan durante el registro de la página.
Los resultados de la búsqueda estarán determinados por la información que se haya
suministrado al directorio cuando se haya registrado la web. A diferencia de los motores,
son revisadas por operadores humanos, y clasificadas según categorías, de forma que es
más fácil encontrar webs del tema de nuestro interés.
Los resultados se presentan haciendo referencia a los contenidos y temática de la web. Su
tecnología es muy barata y sencilla. Son apropiados para buscar categorías, mas que
informaciones específicas, y para visitar sitios de temática común. Es la tecnología que
utilizan portales y buscadores de sectores especializados como economía, derecho,
naturaleza, deportes, famosos, humanidades, .. ..
Ejemplos de directorios: Yahoo, Terra (Antiguo Olé). Ahora, ambos utilizan tecnología
spider, aunque Yahoo conserva su directorio. Buscar Portal es un directorio, y la mayoría de
motores hispanos son directorios.
5.4.2.1 FFA (Free For All)

FFA son páginas de enlaces gratuitos para todos. Cualquiera puede inscribir su página
durante un tiempo limitado en estos pequeños directorios. Los enlaces no son
permanentes.
5.4.3 Sistemas mixtos

Conviene señalar las características que hacen diferentes a los motores de búsqueda
respecto a los directorios temáticos o catálogos de la Red. A pesar de que el objetivo de

ambos tipos de herramientas es facilitar al usuario la información que éste solicita, la
filosofía de unos y otros no es la misma.
Fundamentalmente, la diferencia radica en la forma que tienen de buscar información y
en la manera de presentarla al usuario. Mientras que en los motores de búsqueda son los
robots los que, de manera automática, recorren la Red siguiendo los enlaces
hipertextuales para localizar e indizar nuevos documentos, en los directorios existe una
selección, una clasificación y una indización de páginas web realizadas por personas.
Por lo tanto, el planteamiento de los motores es intentar recoger toda la información
existente en la web y ofrecer al usuario un sistema de interrogación que le permita realizar
una selección de entre los resultados recuperados; en cambio, los directorios temáticos
ofrecen la información contenida en un número limitado de páginas web previamente
seleccionadas por su interés y la organizan de forma jerárquica, de manera que el usuario
pueda descender los niveles de especificidad necesarios hasta encontrar la información
adecuada a sus necesidades.
Las diferencias entre motores -o buscadores- y directorios son notables. En principio, ni unos
ni otros son la solución ideal para asegurar una correcta y completa recuperación de
información en el web, pero quizá sí lo sea, por el momento, la combinación de ambos.
Para búsquedas muy concretas y definidas, es recomendable el uso de un motor, ya que
hará una búsqueda exhaustiva en todo el web con poca posibilidad de recuperar
documentos no relevantes. Si, por el contrario, lo que se quiere localizar es información
acerca de un tema en general, conviene comenzar la búsqueda por un directorio, ya que
proporcionará documentos relevantes sobre dicho asunto y en esas páginas se
encontrarán enlaces a otras con información relacionada.
Los sistemas mixtos Buscador – Directorio son una mezcla entre buscadores y directorio.
Además de tener características de buscadores, presentan las webs registradas en
catálogos sobre contenidos concretos, que a su vez se dividen en subsecciones.
Como ejemplo de sistemas mixtos se pueden citar: Excite, Voila, Infoseek. Los motores en la
actualidad tienden hacia sistemas mixtos como ha ocurrido con Altavista.
5.4.4 Metabuscadores
Los metabuscadores, en realidad, no son buscadores. Lo que hacen es realizar búsquedas
en auténticos buscadores, analizan los resultados de la página, y presentan sus propios
resultados. No suelen ser bienvenidos por los buscadores, ya que el buscador pone el
dinero para operar el servicio, pone los contenidos que utilizará el metabuscador, y no
percibe nada a cambio. Al eliminar la publicidad, no se obtienen ingresos. Solo gasto y
pérdida de visitantes que utilicen este servicio de búsqueda.
5.4.5 Herramientas comerciales

Cada motor posee unas características a la hora de almacenar, indizar, recuperar y
presentar la información recogida por el robot que lo hacen ser más o menos adecuado
como herramienta de búsqueda y recuperación documental.
Son demasiados para conocer y usarlos todos, pero a pesar de la gran oferta que existe
de este tipo de herramientas, la mayoría de las consultas se realizan en un número mucho
menor de buscadores. Algunos de los más utilizados actualmente son:
x Google
x AltaVista
x Excite
x HotBot

x InfoSeek
x Lycos
x OpenText Index
No existe el motor de búsqueda ideal, aquel que solucionará siempre con la mayor
relevancia y especificidad posible nuestra necesidad de información -¡tampoco existe el
usuario perfecto!-, pero sí existen motores que ofrecen posibilidades que otros no poseen.
En AltaVista destacan la flexibilidad de la consulta avanzada a la hora de introducir la
cadena de búsqueda combinando los operadores booleanos y de proximidad, la opción
de introducir los términos de mayor importancia que servirán para ordenar los resultados, y
la selección del idioma en el que se quieren recuperar los documentos. De Excite cabe
resaltar la opción more like this que aparece junto a cada resultado y la posibilidad de
ordenar los items recuperados por sitio web. En HotBot aparecen las limitaciones de
búsqueda por fecha, lugar geográfico o dominio y tipo de documento, que suponen un
valor añadido respecto a los buscadores que no incluyen estas opciones. De InfoSeek hay
que señalar el servicio de recuperación de imágenes ImageSeek, la restricción de la
búsqueda a un conjunto de documentos recuperados con anterioridad y el listado de
términos relacionados con los introducidos como secuencia de interrogación. Lycos
cuenta con una gama de servicios muy amplia y operadores de proximidad. Y por último,
OpenText Index posee la opción de buscar documentos similares a uno determinado,
varias versiones en otros idiomas y la posibilidad de limitar las búsquedas a determinados
campos de los documentos.
Operadores booleanos
Todos los motores analizados excepto InfoSeek permiten recurrir al álgebra de Boole, unos
sólo en la opción de búsqueda avanzada, otros también en la búsqueda simple. Algunos -
los menos- permiten introducir directamente la ecuación de búsqueda booleana en la
ventana de interrogación, como ocurre en AltaVista en la pantalla de búsqueda
avanzada. Otros presentan menús desplegables con las opciones booleanas, por ejemplo
en la versión en español de Lycos y en OpenText Index; pero es cada vez más habitual que
los creadores de motores intenten simplificar al usuario el manejo de la herramienta y en
lugar de ofrecer los operadores directamente lo hacen por medio de explicaciones: en
lugar de Y utilizan la frase “todos los términos deben estar incluidos en los documentos”, en
lugar de O “algunos de los términos aparecerán en los documentos” y en lugar de NO
“términos que no deben aparecer en los documentos”. Esta manera de esconder los
operadores la ha adoptado entre otros HotBot en las pantallas de búsqueda simple y
avanzada. La facilidad de uso de los booleanos por medio de menús desplegables tiene
como inconveniente que se pierde la posibilidad de agrupar con paréntesis los términos y
los operadores para crear subsecuencias de búsqueda.
Operadores de presencia y ausencia
La mayoría de los motores incluyen estos operadores; de los elegidos la tienen AltaVista,
Excite y HotBot, en la búsqueda avanzada, e InfoSeek.
Operadores de proximidad
Esta opción está disponible en InfoSeek encerrando los términos entre comillas o guiones,
en la búsqueda avanzada de AltaVista, Excite y Lycos, y desde la simple y avanzada de
HotBot y Open Text Index.
El operador de proximidad que más a menudo incluyen los buscadores, aparte de la
búsqueda de frases, es Near. Está disponible en la pantalla de búsqueda avanzada de
AltaVista, en InfoSeek encerrando los términos entre paréntesis, en Lycos y OpenText Index.
Otros operadores de proximidad menos habituales son los que indican que un término esté
antes o después que otros. Los encontramos en Lycos y en OpenText Index.

Operadores de comparación
Esta opción está recogida en AltaVista y en HotBot.
Truncamiento
AltaVista permite truncar los términos con el símbolo del asterisco (*). InfoSeek considera, a
no ser que se encierren los términos uno a uno entre comillas, que todas las palabras están
truncadas por la parte final, es decir, que realiza una comparación parcial o steeming;
habrá que tenerlo en cuenta al realizar las consultas, ya que una búsqueda por sal podría
darnos como resultado documentos sobre el salmón o sobre saltos de altura.
Lo mismo le ocurre a Lycos, donde se marcará el fin de las palabras con un punto (.), ya
que, si no, busca todas las palabras que comiencen con los caracteres introducidos. El
truncamiento en Lycos en otra parte de los términos se indica con el símbolo del dólar ($).

Tema IV.II.3 La seguridad en redes. Control de accesos.
Técnicas criptográficas. Mecanismos de firma
digital. Intrusiones. Cortafuegos.
Índice
1.- SEGURIDAD EN REDES 3
1.1 Conceptos de Seguridad 3
1.2 Servicios de Seguridad 3
1.3 Amenazas 4
1.3.1 Relación entre Amenazas y Servicios de Seguridad 5
1.4 Mecanismos de seguridad 5
1.5 Comunicaciones seguras sobre redes inseguras 6
1.6 Seguridad en Internet 7
1.6.1 Seguridad en correo electrónico 10
1.6.2 Seguridad en comercio electrónico 14
2.- CONTROL DE ACCESOS 16
2.1 Mecanismos de identificación y autenticación 17
2.1.1 Contraseña 17
2.1.2 Constantes biométricas 17
2.1.3 Tarjetas inteligentes 17
2.1.4 Encaminamiento y direcciones de red 17
2.1.5 Dominios lógicos 18
2.2 Diccionario de seguridad 18
2.3 Kerberos 18
3.- TÉCNICAS CRIPTOGRÁFICAS 19
3.1 Algoritmos simétricos 20
3.1.1 DES 20
3.1.2 DES Múltiple 21
3.1.3 RC-2 y RC-4 21
3.1.4 IDEA 21
3.1.5 Rijndael 22
3.1.6 Otros algoritmos 22
3.2 Algoritmos asimétricos 22
3.2.1 RSA 23
3.2.2 El Gamal 23
3.2.3 Estándares de criptografía de clave pública PKCS 24
3.3 Sistemas híbridos 25
4.- CRIPTOANÁLISIS 26
5.- MECANISMOS DE FIRMA DIGITAL 26
5.1 Función resumen (hash) 27
5.1.1 MD (Message Digest) 27
5.1.2 SHA y SHA-1 28
5.1.3 SHS 28
5.2 Certificación de claves 29
Temario Oposiciones TIC 1 Tema IV.II.03

5.2.1 Autoridades de certificación 29
5.2.2 Certificado digital 29
6.- INTRUSIONES 30
6.1 Tipos de ataques 30
6.1.1 Ataques pasivos
6.1.2 Ataques activos
6.2 Sistemas de detección de intrusos IDS 30
6.2.1 Clasificación de los IDS 31
7.- CORTAFUEGOS 31
7.1 Routers de filtrado de paquetes 32
7.2 Nivel de aplicación 33
7.3 Pasarela a nivel de circuitos 34
7.4 Arquitecturas de seguridad usando cortafuegos 34
7.4.1 Cortafuegos de filtrado de paquetes 34
7.4.2 Dual-Homed Host 34
7.4.3 Screened Host 35
7.4.4 Screened Subnet (DMZ) 35
7.4.5 Otras arquitecturas 36

1.- Seguridad en redes
El objetivo de la seguridad de los sistemas de información es mantener la continuidad de
los procesos de la organización. La creciente conectividad entre sistemas a través de
redes de comunicaciones hace que la organización esté expuesta a amenazas contra su
seguridad. La seguridad depende tanto de los medios técnicos como de las políticas
directivas y operativas de la organización. Depende de los usuarios y no de la
infraestructura. En este sentido hay que saber que la mayoría de las amenazas se deben al
acceso no autorizado.
La evolución de los sistemas de información nos ha llevado desde los centros de proceso
de datos, donde la seguridad fundamentalmente consistía en controlar el acceso a los
mismos hasta los actuales sistemas de información distribuida, donde no se puede
garantizar el control del acceso a las redes de información
1.1 Conceptos de Seguridad

A continuación se definen algunos conceptos básicos relativos a la seguridad:
– INTEGRIDAD
Se define como la característica que previene contra la modificación o destrucción no
autorizadas de los activos.
– DISPONIBILIDAD
Se define como la característica que previene contra la denegación no autorizada de
acceso a los activos.
– CONFIDENCIALIDAD
Se define como la característica que previene contra la divulgación no autorizada de
los activos.
– AUTENTICACIÓN
Se define como la característica de dar y reconocer la autenticidad de los activos (de
tipo información) y/o la identidad de los actores y/o la autorización por parte de los
autorizadores, así como la verificación de dichas tres cuestiones.
– ACTIVOS DEL SISTEMA
Se entiende por activos a los recursos del sistema de información o relacionados con
éste, necesarios para que la organización funcione correctamente y alcance los
objetivos propuestos por su dirección.
– SERVICIOS Y MECANISMOS DE SEGURIDAD
Los servicios de seguridad constituyen el qué, mientras que las técnicas y mecanismos
de seguridad constituyen el cómo en la implantación de la seguridad. Así una técnica
o mecanismo de seguridad es la lógica o algoritmo que implementa un servicio de
seguridad particular en hardware y software.
1.2 Servicios de Seguridad

Dentro del modelo de referencia OSI, se define una arquitectura de seguridad
(“Information Processing Systems. OSI Reference Model - Part 2: Security Arquitecture”,

ISO/IEC IS 7498-2). De acuerdo con esta arquitectura, para proteger las comunicaciones
de los usuarios a través de una red, es necesario dotar a las mismas con una serie de
servicios, que se conocen como servicios de seguridad:
x Autenticación de la entidad par: este servicio verifica la fuente de los datos. La
autenticación puede ser sólo de la entidad origen, de la entidad destino o de
ambas a la vez. Garantiza al receptor la identidad del remitente del mensaje y
viceversa. Desde otro punto de vista garantiza la identidad del servidor o del
cliente.
x Control de acceso: este servicio verifica que sólo acceden a la información y a los
recursos quienes tienen derecho a hacerlo.
x Confidencialidad de los datos: este servicio evita que se revelen, deliberada o
accidentalmente, los datos de una comunicación.
x Integridad de los datos: este servicio verifica que los datos de una comunicación
no se alteren, esto es, que los datos recibidos por el receptor coincidan por los
enviados por el emisor.
x No repudio: este servicio proporciona la prueba, ante una tercera parte, de que
cada una de las entidades han participado, efectivamente, en la comunicación.
Puede ser de dos tipos:
o con prueba de origen o emisor: el destinatario tiene garantía de quién es el
emisor concreto de los datos.
o con prueba de entrega o receptor: el emisor tiene prueba de que los datos
de la comunicación han llegado íntegramente al destinatario correcto en
un instante dado.
Los servicios de seguridad son la forma de responder a las amenazas para satisfacer los
requisitos de seguridad de la organización.
1.3 Amenazas
Algunas de las amenazas sobre el sistema informático se describen a continuación:
– Captura de información en tránsito
La información permanece inalterada, pero se compromete su privacidad. Afecta al
estado de CONFIDENCIALIDAD de la información.
– Modificación de información en tránsito
La información es sustituida por otra antes de la entrega al destinatario. Afecta al
estado de INTEGRIDAD de la información.
– Simulación de identidad
La información es encaminada a una entidad (usuario, aplicación informática o
servidor) que se hace pasar por el destinatario deseado. Afecta al estado de
AUTENTICACIÓN de la entidad.Esta puede ser:
– Suplantación de identidad
Falsificación de identidad
– Denegación de acceso
Una entidad con derechos de acceso a la información no puede acceder a ésta.
Afecta al estado de DISPONIBILIDAD de la información.

1.4 Relación entre Amenazas y Servicios de Seguridad
La siguiente tabla muestra la relación existente entre cada tipo de amenaza y el servicio
de seguridad correspondiente.
Amenaza Servicio de Seguridad
Divulgación no autorizada de la Confidencialidad de datos
información
Modificación no autorizada de la Integridad del mensaje y del
información contenido
Enmascaramiento o suplantación Autenticación de entidades
Repudio del mensaje de origen o del No repudio
acuse de recibo
Acceso no autorizado a recursos Control de acceso
Denegación de servicio Disponibilidad
1.5 Mecanismos de seguridad

Las técnicas y mecanismos de seguridad constituyen cómo implantar la seguridad. Así una
técnica o mecanismo de seguridad es la lógica o algoritmo que implementa un servicio
de seguridad particular en hardware y software.
Para proporcionar los servicios de seguridad citados, es necesario incorporar en los niveles
adecuados del modelo de referencia OSI los siguientes mecanismos de seguridad:
1.5.1 Cifrado
El cifrado puede hacerse mediante el uso de criptosistemas simétricos o asimétricos y
puede aplicarse extremo a extremo o a cada enlace del sistema de comunicaciones. El
mecanismo de cifrado soporta el servicio de confidencialidad de los datos y puede
complementar a otros mecanismos para conseguir diversos servicios de seguridad.
1.5.2 Firmado digital

La firma digital se puede definir como un conjunto de datos que se añaden a una unidad
de datos de modo que protejan a ésta contra cualquier falsificación, permitiendo al
receptor comprobar el origen y la integridad de los datos. Para ello, se cifra la unidad de
datos junto con alguna componente secreta del firmante, y se obtiene un valor de control
ligado al resultado cifrado. El mecanismo de cifrado digital soporta los servicios de
integridad de los datos, autenticación del emisor y no repudio con prueba de origen. Para
que se pueda proporcionar el servicio de no repudio con prueba de entrega, hay que
forzar al receptor para que envíe un acuse de recibo firmado digitalmente.
1.5.3 Control de acceso

Se una para autentificar las capacidades de una entidad para acceder a un recurso
dado. El control de acceso se puede llevar a cabo en el origen o en un punto intermedio,
y se encarga de asegurar que el emisor está autorizado a comunicarse con el receptor o a
usar los recursos de comunicación. El mecanismo de control de acceso soporta el servicio
de control de acceso.

1.5.4 Integridad de datos
Hay que distinguir entre la integridad de una unidad de datos individual y la integridad de
una secuencia de unidades de datos. Para lograr integridad de una unidad de datos, el
emisor añade datos suplementarios a la unidad de datos. Estos datos suplementarios se
obtienen en función de la unidad de datos y, generalmente, se cifran. El receptor genera
los mismos datos suplementarios a partir de la unidad original y los compara con los
recibidos. Para proporcionar integridad a una secuencia de unidades de datos se
requiere, adicionalmente, algún mecanismo de ordenación, tal como el uso de números
de secuencia, un sello temporal o un encadenamiento criptográfico entre las unidades. El
mecanismo de integridad de datos soporta el servicio de integridad de datos.
1.5.5 Autenticación
El intercambio de autenticación tiene dos grados:
x autenticación simple: el emisor envía su identificador y una contraseña al receptor, el
cual los comprueba.
x autenticación fuerte: utiliza propiedades de los criptosistemas de clave pública. Un
usuario se autentifica mediante su identificador y su clave privada. Su interlocutor
debe verificar que aquel, efectivamente, posee la clave privada, para lo cual debe
obtener, de algún modo, la clave pública del primero. Para ello deberá obtener su
certificado. Un certificado es un documento firmado por una Autoridad de
Certificación (una tercera parte de confianza) y válido durante el periodo de tiempo
determinado, que asocia una clave pública a un usuario.
El mecanismo de intercambio de autenticación soporta el servicio de autenticación de
entidad par.
1.6 Comunicaciones seguras sobre redes inseguras

Los mensajes sin transformar de ninguna manera se denominan texto en claro (también
llamado, según una no muy adecuada traducción, texto plano). El proceso mediante el
cual la información contenida en el mensaje es ocultada se denomina cifrado. Un mensaje
cifrado se denomina, obviamente, texto cifrado. El proceso mediante el que se revierte el
proceso de ocultación, obteniendo el texto en claro a partir del texto cifrado se denomina
descifrado. Hay que señalar que los términos encriptar y desencriptar no existen en
castellano.
Se trata de permitir que dos entidades, ya sean usuarios o aplicaciones, puedan enviarse
mensajes por un canal que puede ser intervenido por una tercera entidad, de modo que
sólo los destinatarios autorizados puedan leer los mensajes. Como paradigma de red
insegura consideraremos Internet, que es, previsiblemente, la red de redes sobre la que se
llevarán a cabo las transacciones comerciales del futuro.
El texto en claro se representa como M (por message) o también por P (de plain text). M es
simplemente un dato binario. El texto cifrado se designa por C (de ciphertext). No existe
relación directa entre los tamaños de ambos mensajes. Unas veces su tamaño coincide.
Otras, el del texto cifrado es mayor que el del texto en claro. Puede ocurrir, incluso, que el
texto cifrado sea de menor tamaño. Esto sucede cuando, además de las técnicas de
cifrado, se emplean técnicas de compresión.
La función de cifrado, E, opera sobre M para producir C. En notación matemática:
E (M) = C
Inversamente, la función de descifrado, D, se aplica a C para producir M:

D (C) = M
En todo caso, debe cumplirse la siguiente igualdad:
D ( E(M) ) = M
Un algoritmo criptográfico es una función matemática utilizada para el cifrado y
descifrado de mensajes. Generalmente, hay dos funciones relacionadas: una para el
cifrado y otra para el descifrado.
1.7 Ataques en redes

Una comunicación, protegida o no mediante sistemas criptográficos, está sujeta a una
gran variedad de ataques de los cuales es imposible dar una taxonomía completa.
1.7.1 Ataques más habituales

Los citados habitualmente son los siguientes:
x ataque sólo al criptograma: es el más desfavorable para el intruso o criptoanalista. En
este caso, sólo tiene acceso al texto cifrado. El trabajo del intruso consiste en recuperar
el texto en claro de tantos mensajes como sea posible. En tales condiciones, y aunque
conociera el algoritmo de cifrado, sólo puede intentar vulnerar dicho algoritmo, realizar
un análisis estadístico de los criptogramas o probar todas las claves posibles del
algoritmo. Este último caso, por motivos obvios se conoce como búsqueda exhaustiva
o también como ataque basado en fuerza bruta.
x ataque mediante texto en claro conocido: en este ataque, más ventajoso para el
atacante, éste se ha hecho con pares de texto en claro y su equivalente cifrado o ha
adivinado, de algún modo, el contenido del mensaje (muchos mensajes cifrados,
correspondientes a protocolos normalizados, reproducen la misma estructura o poseen
las mismas palabras en los mismos sitios del mensaje). Estas parejas pueden ser usadas
para llevar a cabo el criptoanálisis y averiguar la clave, lo cual será útil si se usa la
misma clave para posteriores comunicaciones.
x ataque mediante texto en claro escogido: ataque mucho más eficaz que el anterior
en el que el intruso es capaz, de algún modo, de conseguir que un texto elegido por él
sea cifrado con la clave desconocida. Por tanto hay que diseñar el sistema
criptográfico de modo que nunca un intruso pueda introducir mensajes propios.
x ataque adaptable mediante texto en claro escogido: caso especial del anterior en el
que el intruso no sólo puede elegir el texto que quiere cifrar, sino que puede tomar
decisiones sobre el texto que ser cifra basadas en resultados anteriores.
x ataque mediante criptogramas escogidos: el atacante puede obtener el descifrado
de diversos mensajes cifrados escogidos por el.
Aunque se pueden diseñar otros ataques criptoanalíticos, los citados son los más
frecuentes. En el marco de una comunicación entre dos entidades, se puede hablar de
los siguientes ataques, que pueden servir para implementar alguno de los anteriores:
x escucha pasiva (passive eavesdropping): el intruso simplemente escucha el tráfico que
circula por el canal.
x tercero interpuesto (man-in-the-middle): el intruso, de alguna forma, se coloca entre los
dos interlocutores y hace creer a cada uno de ellos que es su interlocutor.
x retransmisión ciega (replay): el intruso intercepta un mensaje legítimo, lo almacena (sin
eliminarlo) y lo reenvía un tiempo después.

x cortado-y-pegado (cut-and-paste): dados dos mensajes cifrados con la misma clave,
a veces es posible combinar partes de los dos para producir uno nuevo. El intruso no
sabe lo que dice este nuevo mensaje, pero puede utilizarlo para confundir a los
interlocutores legítimos e inducir a alguno de ellos a hacer algo beneficioso para el
intruso.
x puesta a cero del reloj (time-resetting): en protocolos que utilizan de alguna forma la
hora actual, el intruso puede tratar de confundirnos acerca de cuál es la verdadera
hora.
1.7.2 Categorías de ataques

Las cuatro categorías generales de amenazas o ataques son las siguientes:
Flujo normal
Fuente Destino
Interrupción
Intercepción
Modificación
Fabricación
x Interrupción: un recurso del sistema es destruido o se vuelve no disponible. Este es un

ataque contra la disponibilidad. Ejemplos de este ataque son la destrucción de un
elemento hardware, como un disco duro, cortar una línea de comunicación o
deshabilitar el sistema de gestión de ficheros.
x Intercepción: una entidad no autorizada consigue acceso a un recurso. Este es un

ataque contra la confidencialidad. La entidad no autorizada podría ser una persona,
un programa o un ordenador. Ejemplos de este ataque son pinchar una línea para
hacerse con datos que circulen por la red y la copia ilícita de ficheros o programas
(intercepción de datos), o bien la lectura de las cabeceras de paquetes para desvelar
la identidad de uno o más de los usuarios implicados en la comunicación observada
ilegalmente (intercepción de identidad).
x Modificación: una entidad no autorizada no sólo consigue acceder a un recurso, sino

que es capaz de manipularlo. Este es un ataque contra la integridad. Ejemplos de este
ataque son el cambio de valores en un archivo de datos, alterar un programa para
que funcione de forma diferente y modificar el contenido de mensajes que están
siendo transferidos por la red.

x Fabricación: una entidad no autorizada inserta objetos falsificados en el sistema. Este
es un ataque contra la autenticidad. Ejemplos de este ataque son la inserción de
mensajes espurios en una red o añadir registros a un archivo.
Estos ataques se pueden asimismo clasificar de forma útil en términos de ataques pasivos y
ataques activos.
1.7.2.1 Ataques pasivos

En los ataques pasivos el atacante no altera la comunicación, sino que únicamente la
escucha o monitoriza, para obtener información que está siendo transmitida. Sus objetivos
son la intercepción de datos y el análisis de tráfico, una técnica más sutil para obtener
información de la comunicación, que puede consistir en:
x Obtención del origen y destinatario de la comunicación, leyendo las cabeceras de los

paquetes monitorizados.
x Control del volumen de tráfico intercambiado entre las entidades monitorizadas,

obteniendo así información acerca de actividad o inactividad inusuales.
x Control de las horas habituales de intercambio de datos entre las entidades de la

comunicación, para extraer información acerca de los períodos de actividad.
Los ataques pasivos son muy difíciles de detectar, ya que no provocan ninguna alteración
de los datos. Sin embargo, es posible evitar su éxito mediante el cifrado de la información y
otros mecanismos que se verán más adelante.
1.7.3 Ataques activos

Estos ataques implican algún tipo de modificación del flujo de datos transmitido o la
creación de un falso flujo de datos, pudiendo subdividirse en cuatro categorías:
x Suplantación de identidad: el intruso se hace pasar por una entidad diferente.

Normalmente incluye alguna de las otras formas de ataque activo. Por ejemplo,
secuencias de autenticación pueden ser capturadas y repetidas, permitiendo a una
entidad no autorizada acceder a una serie de recursos privilegiados suplantando a la
entidad que posee esos privilegios, como al robar la contraseña de acceso a una
cuenta.
x Reactuación: uno o varios mensajes legítimos son capturados y repetidos para producir
un efecto no deseado, como por ejemplo ingresar dinero repetidas veces en una
cuenta dada.
x Modificación de mensajes: una porción del mensaje legítimo es alterada, o los

mensajes son retardados o reordenados, para producir un efecto no autorizado. Por
ejemplo, el mensaje “Ingresa un millón de pesetas en la cuenta A” podría ser
modificado para decir “Ingresa un millón de pesetas en la cuenta B”.
x Degradación fraudulenta del servicio: impide o inhibe el uso normal o la gestión de

recursos informáticos y de comunicaciones. Por ejemplo, el intruso podría suprimir todos
los mensajes dirigidos a una determinada entidad o se podría interrumpir el servicio de
una red inundándola con mensajes espurios. Entre estos ataques se encuentran los de
denegación de servicio (DoS Denial of Service), consistentes en paralizar
temporalmente el servicio de un servidor de correo, Web, FTP, etc.

1.8 Seguridad en Internet
1.8.1 Seguridad en correo electrónico

El correo electrónico es uno de los sistemas telemáticos más vulnerables a los ataques a la
seguridad.
Los primeros sistemas de seguridad funcionaban directamente sobre SMTP (Simple Mail
Transfer Protocol):
– PGP(Pretty Good Privacy). Es una aplicación independiente de la máquina y el sistema
operativo que integra diversos algoritmos de seguridad. Fue inventado por un
particular, Phil Zimmerman, y no tiene restricciones legales para la distribución. También
es un estándar de Internet (RFC 1991 del IETF).
– PEM. Fue desarrollado por la agencia de seguridad de EE.UU. (NSA) y, por lo tanto,
tiene muchas restricciones legales. Esto no ha permitido que se desarrollara.
Después apareció el estándar de correo MIME (Multipurpose Internet Mail Extension) como
una extensión al SMTP para contenidos multimedia y corregir defectos del anterior sistema.
– MOSS. Es el PEM adaptado a MIME y con algunas mejoras.
– PGP/MIME y OpenPGP. Son versiones del PGP adaptadas a MIME y con algunas
mejoras.
– S/MIME . Sistema abierto inventado por la empresa RSA Inc. y actualmente un estándar
de la IETF.
Hoy en día parece que solamente se extienden el OpenPGP y el S/MIME. El primero se
utiliza entre usuarios doméstico y el segundo para ámbitos profesionales y comercio
electrónico.
1.8.1.1 Multi-purpose Internet Mail Extensions (MIME)

El mecanismo básico de transporte de correo a través de Internet queda definido por SMTP
(Simple Mail Transfer Protocol). El RFC 822 describe el formato de los mensajes
intercambiados. Según este estándar, cada mensaje consta de dos partes:
x header (cabecera): contiene la información necesaria para que el mensaje llegue
a su destino. El formato de la cabecera es definido ambién por el estándar y está
formada por un conjunto de pares clave/valor estructurados.
x body (cuerpo o contenido): la información que debe recibir el destinatario. Esta
información estará siempre en formato de texto de siete bits (US-ASCII).
MIME es un protocolo de intercambio de objetos a través de Internet. Se desarrolló
inicialmente para enriquecer los intercambios de correo electrónico, limitados según el
RFC 822 a ASCII de siete bits, habiéndose extendido a otros muchos protocolos. El formato
MIME permite el envío de texto enriquecido (8 bits), gráficos, ficheros de audio, vídeo, ... En
MIME, cada objeto de mensajería se encapsula en una especie de envoltorio que
especifica tanto su semántica como el medio de codificación utilizado. La caracterización
semántica hecha en la cabecera permite asociar los datos con su mecanismo de
transporte (codificación) y con su significado, de forma que el remitente y el destinatario
utilicen coordinadamente los datos intercambiados.
1.8.1.1 Privacy Enhanced Mail (PEM)

PEM es un sistema similar a MIME y desarrollado en paralelo con éste para crear objetos de
mensajería seguros. Incluye cifrado, autenticación y gestión de claves y permite el uso de

algoritmos simétricos y de clave pública. Con el desarrollo de MIME, PEM es, de alguna
forma, repetitivo, por lo que se ha visto desplazado por S/MIME. De hecho, lleva más de
dos años en estado de borrador.
1.8.1.2 MIME Object Security Objects (MOSS)

MOSS (también conocido como PEM-MIME) es una extensión de MIME derivada de PEM
que aporta exclusivamente lo que le falta a MIME para obtener las garantías deseadas:
claves, firmas digitales, certificados, etc. De este modo se consigue un intercambio seguro
de objetos. De acuerdo con la propia naturaleza de MIME, es posible aplicar diferentes
servicios de seguridad a cada parte del mensaje.
Este estándar ha sufrido críticas debido a sus requerimientos, que son extremadamente
flexibles. Fruto de esta flexibilidad puede ocurrir que dos agentes de correo diferentes,
ambos soportando MOSS, sean incompatibles. Esta flexibilidad es, en parte, una reacción
a la rigidez de PEM, la cual le hacía impopular entre los usuarios.
1.8.1.3 Secure-Multipurpose Internet Mail Extensions (S/MIME)

S/MIME es un protocolo que añade firmas digitales y cifrado a los mensajes MIME. MIME, en
sí mismo, no proporciona ningún servicio de seguridad. S/MIME define esos servicios,
utilizando criptografía de clave pública, siguiendo la sintaxis definida en el PKCS#7.
S/MIME ha sido adoptado recientemente por un gran número de compañías como FTP
Software, Qualcomm, Microsoft, Lotus, VeriSign, Netscape o Novell.
1.8.2 Protocolos seguros de Internet
1.8.2.1 Secure HTTP (S-HTTP)

Secure HTTP es un protocolo propuesto por Enterprise Integration Technologies (EII),
patrocinado por el consorcio CommerceNet y desarrollado en la actualidad por Terisa
Systems. Constituye una extensión del protocolo HTTP, incorporando cabeceras MIME para
aportar confidencialidad, autenticación, integridad e irrenunciabilidad de las
transacciones.
Utiliza un sistema inspirado en PEM, añadiendo suficientes cabeceras a cada transacción
para lograr cada uno de los objetivos propuestos. Las transacciones HTTP constan
simplemente de una petición de parte del cliente que produce una respuesta del servidor.
S-HTTP especifica que el cliente envíe directamente toda la información pertinente: claves,
certificados, códigos de integridad, etc. (incluyendo la posibilidad de referenciar secretos
compartidos obtenibles exteriormente: intercambios previos o bases de datos comunes). El
servidor responde siguiendo la misma filosofía PEM. El protocolo soporta varios mecanismos
criptográficos y negocia los modos y opciones de estos mecanismos.
Evaluación de S-HTTP
Las principales ventajas de S-HTTP son su flexibilidad y su integración dentro de HTML
(extensiones al lenguaje similares a las introducidas periódicamente por Netscape Co. en
sus navegadores).
Entre sus debilidades podemos señalar los efectos derivados de mantener la
compatibilidad hacia atrás y la necesidad de implementar servidores que soporten las
extensiones a HTML aportadas por el protocolo S-HTTP.

1.8.2.2 Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL) es un protocolo diseñado por Netscape Communications Co.,
que dispone un nivel seguro de transporte entre el servicio clásico de transporte en Internet
(TCP) y las aplicaciones que se comunican a través de él. Proporciona conexiones seguras
sobre una red insegura como es Internet, asegurando las siguientes características:
1) conexión privada: la información se cifra utilizando criptografía de clave simétrica.
2) autenticación: usando criptografía de clave pública.
3) integridad: la integridad de los mensajes se asegura usando firmas digitales.
Además, proporciona características adicionales:
1) extensibilidad: es capaz de soportar nuevos protocolos en el futuro.
2) eficiencia: al utilizar compresión, minimiza el tiempo necesario para establecer la
conexión.
3) compatibilidad: productos con diferentes versiones de SSL pueden interoperar entre
sí.
SSL se compone de dos partes diferenciadas:
1. Handshake Protocol: se encarga de establecer la conexión y determinar los
parámetros que se van a utilizar posteriormente (fundamentalmente se trata de
establecer cual va a ser la clave simétrica que se utilizará para transmitir los datos
durante esa conexión).
2. Record Protocol: comprime, cifra, descifra y verifica la información que se transmite.
Este sistema es transparente para las aplicaciones finales, que simplemente saben que el
canal se encarga de proporcionarles confidencialidad entre extremos. Por tanto,
podemos situar protocolos como HTTP, FTP, NNTP o Telnet.
1.8.2.2.1 Modo de funcionamiento

El denominado Handshake Protocol se compone dos fases, autenticación de servidor y
autenticación de cliente, no siendo obligatoria esta última. En primer lugar, el servidor,
respondiendo a una petición del cliente, le envía su certificado y las preferencias en lo que
a algoritmos de cifrado se refiere. En ese momento, el cliente genera una clave maestra, la
cifra con la clave pública del servidor y la transmite al servidor. El servidor recobra la clave
maestra y se autentica respecto al cliente devolviendo un mensaje cifrado con la clave
maestra. Los datos siguientes son cifrados con claves derivadas de esta clave maestra.
En la segunda fase opcional, el servidor envía un reto al cliente. Éste se autentica respecto
al servidor retornándole el reto firmado digitalmente por el cliente, así como su certificado
(el cual incluye su clave pública).
1.8.2.2.2 Algoritmos utilizados

Una gran variedad de algoritmos criptográficos son soportados por SSL. Durante la fase de
acuerdo o “handshaking”, se utiliza RSA (clave pública). Después del intercambio de
claves, se usan unos cuantos algoritmos, entre los que se incluyen RC2, RC4, IDEA, DES y
Triple-DES. Como función resumen se usa MD5 o SHA-1. Los certificados siguen el formato
X.509.
1.8.2.2.3 Implementación

Los diferentes protocolos que utilizan los servicios de SSL usan puertos diferentes a los que
les correspondería si no fuesen sobre SSL. La IANA ha reservado los siguientes puertos para
su uso por SSL:
x 433: HTTP sobre SSL (https)
x 465: SMTP (correo electrónico) sobre SSL (ssmtp), no confirmado.
x 563: NNTP (servicio de noticias, News) sobre SSL (snntp), no confirmado.
El protocolo SSL está, gracias a los esfuerzos de Netscape, ampliamente extendido. La
presencia de https:// en el URL de un servidor indica se trata de un servidor “seguro” y
que debe utilizarse SSL en la comunicación entre dicho servidor y cliente (navegador). Los
navegadores más extendidos (Netscape Navigator y Microsoft Internet Explorer) son
capaces de “hablar” SSL. Esto queda indicado (en el caso de Netscape Navigator) de la
siguiente forma:
x la llave de la parte inferior izquierda del navegador aparece completa, no partida
como habitualmente (en los casos del MS Internet Explorer y de Netscape
Communicator es un candado cerrado el que aparece en la esquina inferior
izquierda).
x aparece una línea azul en el límite superior de la línea de visualización de la
pantalla del navegador.
x la información del documento alojado en el servidor seguro incluye los datos del
certificado que avala al servidor seguro.
Los servidores más populares de la empresa Netscape (Commerce Server, FastTrack Server
y Enterprise Server) soportan SSL, con las habituales limitaciones de exportación (clave RC4
de 40 bits para los productos vendidos fuera de EE.UU. o Canadá). El servidor más
extendido a escala mundial, Apache, posee una versión SSL, Stronghold, con la ventaja
añadida de que, al haber sido desarrollado fuera de los EE.UU., puede vender la versión
“completa” de SSL con claves de 128 bits. El servidor de Microsoft, Internet Information
Server 2.0, que viene de serie con Windows NT 4.0 no soporta SSL. Las últimas versiones (IIS
4.0) soportan plenamente el estándar (junto con protocolos propios como PCT).
1.8.2.2.4 Conclusión
A diferencia de S-HTTP, que es un protocolo substitutivo de HTTP, SSL extiende su soporte a
otros protocolos habituales en Internet. Esta es una de las principales ventajas que aporta
este último. Mientras que S-HTTP proporciona cifrado en el nivel de aplicación (en este
caso WWW), SSL lo hace en el nivel de conexión, proporcionando un canal seguro en el
nivel de red. Por lo demás, S-HTTP y SSL pueden convivir, utilizándose uno u otro en
diferentes instantes de una transacción comercial, o incluso utilizándose simultáneamente.
El sistema es tan robusto como lo sea el menos seguro de los algoritmos que utilice. Claves
públicas cortas o claves DES o RC4 de 40 bits deben utilizarse con precaución. Estos son los
problemas que plantean las leyes de EE.UU.
La principal desventaja de SSL no estriba en sus fundamentos teóricos o implementación,
sino, fundamentalmente, la menor protección que proporcionan las versiones exportables
de los productos basados en este protocolo.
También debe tenerse especial cuidado en decidir qué autoridades de certificación y qué
certificados son fiables.

1.8.3 Seguridad en comercio electrónico
1.8.3.1 SET (Secure Electronic Transactions)

Durante 1995, las grandes compañías mundiales de tarjetas de crédito presentaron sendas
proposiciones de comercio electrónico, con vistas a incorporar los prácticamente
universales medios de pago electrónicos al mundo de Internet. Visa, en colaboración con
Microsoft, desarrolló una especificación completa, la Secure Transactions Technology (STT).
Por otra parte, MasterCard, en asociación con IBM, Netscape y CyberCash patrocinó una
especificación conocida como Secure Electronic Payment Protocol (SEPP). Ambas
especificaciones se basaban en el uso de criptografía de clave pública, certificados...
Ante la previsible guerra que se adivinaba, ambos gigantes, junto con los consorcios que
les apoyaban, decidieron asociarse y presentaron, en febrero de 1996, una especificación
abierta para conseguir la protección de los pagos hechos mediante tarjeta de crédito en
cualquier red insegura y, específicamente, en Internet. American Express se unió al
consorcio poco después de la publicación del primer borrador. Se consideó que las
primeras implementaciones se desarrollarían durante el año 1997.
Esta especificación se denomina SET (Secure Electronic Transactions).
1.8.3.1.1 Objetivos
Los objetivos que persigue el desarrollo del protocolo SET son los siguientes:
1. definir un estándar único para efectuar transacciones a través de Internet,
evitando la competencia entre diferentes estándares auspiciados por distintas
empresas y consorcios.
2. este estándar debe ser similar a y compatible con los sistemas de pago mediante
tarjeta existentes en la actualidad.
3. proveer la autenticación de todas las partes implicadas en una transacción.
4. mantener la confidencialidad de la información intercambiada, de forma que
cada parte no tenga acceso a más información que la estrictamente necesaria
para llevar a cabo su función en la transacción.
5. mantener la integridad de la información implicada en los pagos.
6. ser independiente de plataformas y navegadores.
1.8.3.1.2 Actores de la transacción

Los actores implicados en una transacción de comercio electrónico utilizando el modelo
SET son los siguientes:
1. el tenedor de la tarjeta de crédito (cliente): puede ser una persona física o jurídica.
Utiliza una tarjeta de crédito emitida por la institución correspondiente. El cliente está
equipado con el correspondiente navegador.
2. el banco emisor: institución financiera con la que A establece una cuenta y que, a su
vez, emite una tarjeta a su nombre.
3. el comercio: establecimiento que ofrece bienes, servicios, informaciones... a un
precio. El comercio debe tener una cuenta con un banco.
4. el banco del comercio: institución financiera con la que el comercio establece una
cuenta. Se encarga de procesar las autorizaciones de pago y realiza el pago al
comercio.

5. la red de compensación: procesa la transferencia de dinero entre las instituciones
financieras involucradas.
6. la autoridad de certificación: avala las claves públicas de las partes, emitiendo
certificados para cada una de ellas.
1.8.3.1.3 Funcionamiento
Veamos como se desarrollaría un caso práctico de comercio electrónico:
1. el cliente, tenedor de una tarjeta (siguiendo con nuestro usuario imaginario, A)
accede al comercio y navega por él, seleccionando una serie de productos.
2. A rellena una orden de compra, calculándose el monto total de la operación
(incluyendo los gastos de envío).
3. A selecciona el método de pago (tarjetas Visa, MasterCard, American Express...).
4. A envía su orden de pago con el método de pago elegido al comercio.
5. el comercio solicita autorización por parte del banco de A para llevar a cabo la
transacción.
6. el comercio le envía a A la confirmación (en forma de factura pro-forma, por
ejemplo) de la compra.
7. el comercio envía los bienes comprados a A.
8. el comercio solicita a su banco el abono de los bienes comprados.
La confidencialidad e integridad de los mensajes entre las partes implicadas en el modelo
se logra utilizando mecanismos de clave secreta (DES) y de clave pública (RSA). Los
mensajes son cifrados con claves DES de 56 bits. La clave DES se genera aleatoriamente,
es cifrada utilizando el algoritmo RSA con la clave pública del destinatario (cuya longitud
es 1024 bits) y añadida al mensaje. Esto es lo que se conoce como “sobre digital” (digital
envelope).
Se utilizan también firmas digitales para garantizar la integridad de los mensajes, junto con
la autenticación del remitente del mensaje. Mediante una función resumen se calcula un
resumen de 160 bits, que a continuación es cifrado con la clave privada del remitente, y
enviada junto con el resto del mensaje. SET emplean dos pares distintos de claves
asimétricas: uno para el cifrado y descifrado de las claves simétricas y otro par para
funciones de firma digital.
La autenticación de las partes queda encomendada al uso de certificados. Estos
certificados son emitidos por las consiguientes autoridades, las cuales deben cumplir una
serie de requisitos de confianza por parte de los actores de la transacción. Para cada uno
de los actores debe emitirse un certificado.
La emisión y verificación de los certificados está fundamentada en una jerarquía de
confianza, con delegación de mayor a menor nivel en el que los certificadores a nivel
mundial van certificando a nuevas autoridades distribuidas por zonas geopolíticas, países,
etc. El seguimiento de este árbol de confianza hacia arriba permite asegurar la
autenticidad de un certificado. Los mecanismos de aceptación y verificación de
certificados deben ir empotrados en los programas.
El comprador obtiene sus certificados de la entidad financiera que emite la tarjeta con la
que opera. El comerciante los obtiene de la entidad financiera con la que ha firmado un
contrato de adhesión para aceptar las diferentes tarjetas de crédito o débito emitidas por
dicha entidad.
El banco o entidad financiera del comerciante debe poseer una certificación de nivel
superior para operar a su vez como autoridad certificadora y emitir certificados para los

comerciantes. Al igual que en el caso de la entidad financiera del comerciante, el banco
del comprador debe poseer también un certificado, puesto que realiza las mismas
funciones que aquel. Ambos obtendrán sus certificados de las asociaciones de medios de
pago.
1.8.3.1.4 Conclusiones
El protocolo SET es la respuesta de las grandes compañías mundiales de medios de pago
al desafío del comercio electrónico. Cuentan como aliados a los grandes del mundo de la
informática. Como no podía ser menos, resuelve de forma completa los problemas de
autenticación de las partes, confidencialidad e integridad de los datos y no repudiación.
2.- Control de accesos

El control de acceso es un mecanismo de seguridad que se ocupa de los procedimientos
de control para el acceso a los activos, servicios o datos de los sistemas de información. El
control de acceso ha de seguir la política de seguridad de la Organización. Este
mecanismo trata de resolver los problemas de identificación y autenticación. Para su
implementación se dispone de diversos posibilidades como el uso de contraseñas, cifrado,
tarjetas de seguridad inteligentes, o constantes biométricas.
Existen dos tipos de acceso:
x Acceso directo
x Acceso por red de comunicaciones
Las redes deben incorporar salvaguardas que impidan a los usuarios remotos y los servicios
de la red comprometer la seguridad de ningún otro servicio conectado a la misma. Estas
salvaguardas deben incluir:
1. Sistemas de identificación, asignación y cambio de derechos de acceso,
control de accesos de los usuarios, que sean consistentes con las directrices
corporativas
2. Autenticación de usuarios, nodos de la red y equipos remotos
3. Restricciones en capacidad de conexión, filtrado del tráfico, restricción de
terminales, desconexión de la sesión, limitación de reintentos
Los mecanismos de autenticación se establecen para usuarios y para nodos de la red.
Para los usuarios, existen hasta tres niveles de autenticación (red, sistema informático,
aplicación). Para los nodos, existen dos niveles (red y aplicación).
Los esquemas de identificación son métodos mediante los que una entidad (un usuario,
una máquina, etc.) puede probar su identidad a alguien distinto a sí mismo, sin revelar
ningún dato propio esencial que permita que un intruso o su mismo interlocutor le
suplanten. Si A se autentifica a sí mismo frente a María, aunque B intercepte el canal, debe
ser imposible para él suplantar a A en el futuro (también debe serlo para María).
Los esquemas de identificación implican que el aspirante:
x demuestra saber algo: palabras de paso.
x demuestra tener algo: una tarjeta magnética, por ejemplo.
x muestra algo característico e indeleble: retina, ADN, ritmo de teclado, ...
x está en un cierto sitio.
x existe un tercero de confianza que lo avala: certificados.

2.1 Mecanismos de identificación y autenticación
2.1.1 Contraseña
La contraseña es un conjunto de caracteres que valida los accesos de un usuario a los
servicios del sistema de información. Es un mecanismo de salvaguarda cuya gestión debe
basarse en las siguientes ideas:
x Contraseñas individuales y seleccionadas por el usuario
x Confirmación de contraseñas
x Registro de contraseñas anteriores para evitar repetición
x Almacenamiento separado de contraseñas y datos
El método tradicional de identificación es el uso de una palabra de paso (password). El

usuario A se identifica a sí mismo frente a un servidor introduciendo su palabra de paso
cuando trata de acceder a su cuenta. Desgraciadamente, este esquema es inseguro. La
palabra de paso puede ser obtenida mediante:
x exposición no autorizada (robo de la palabra de paso).
x adivinación: es un hecho que los usuarios tienden a elegir palabras de paso
inadecuadas, que pueden ser fácilmente adivinadas (utilizando cracks)
x escucha en tránsito: mediante sniffers, por ejemplo.
x reproducción ciega (replay): un intruso que haya interceptado las comunicaciones
entre A y el servidor puede repetir el mensaje previo (es decir, la palabra de paso)
de A, de modo que gane acceso a la cuenta o al recurso del usuario
interceptado.
x alteración del verificador de la palabra de paso.
La autenticación mediante palabra de paso es un ejemplo de esquema de identificación
unilateral, ya que sólo la entidad de uno de los extremos de la comunicación se identifica
a sí misma, sin obtener identificación desde el otro extremo.
2.1.2 Constantes biométricas

El mecanismo basados en constantes biométricas utilizan las características fisiológicas de
la persona (geometría facial, DNA, reconocimiento de retina, huellas dactilares, etc) o su
conducta (utilización del ratón o teclado, reconocimiento de voz, etc) para identificar y
autenticar al usuario autorizado.
2.1.3 Tarjetas inteligentes

Las tarjetas de seguridad son un mecanismo con una banda magnética que almacena
claves, la identidad del propietario de la tarjeta, fecha de caducidad, etc. Las tarjetas
inteligentes además incorporan un microprocesador con memoria y una interfaz.
2.1.4 Encaminamiento y direcciones de red

El encaminamiento en las redes de comunicación puede usarse como salvaguarda frente
a accesos no autorizados. Existen mecanismos para verificar las direcciones de origen y
destino de las comunicaciones por software o hardware. Se puede también seleccionar
una única ruta de acceso a un determinado servicio de forma que se eviten posibles
intrusiones. Incluso pueden existir líneas privadas dedicadas para cierto tipo de conexiones.

2.1.5 Dominios lógicos
Las redes de la organización pueden dividirse en dominios de usuarios y nodos separados
de forma lógica. Cada dominio tiene distintas normas de seguridad, y la segregación se
hace por medio de pasarelas (gateways).
2.2 Diccionario de seguridad

El diccionario de seguridad contiene los privilegios de acceso de usuarios a un sistema de
información. Es una base de datos con información sobre perfiles de usuario, grupos,
permisos de acceso a la información, etc.
2.3 Kerberos
Kerberos es un sistema de autenticación diseñado en el MIT para su utilización sobre redes
inseguras, como, por ejemplo, Internet. El sistema de autenticación Kerberos fue diseñado
con dos propósitos, proveer autenticación y distribuir claves. El sistema Kerberos actúa
como autoridad de certificación que garantiza una relación correcta entre claves y
personas.
Esta autenticación se lleva a cabo usando acreditaciones (tickets). Estas acreditaciones
son sólo válidas durante un periodo de tiempo determinado y en lo que se conoce como
realm (conjunto de máquinas y usuarios, generalmente, coincide con una organización).
Cada usuario (o también un proceso) es conocido como principal. Este principal conecta
con el Centro de Distribución de Claves (Key Distribution Center, KDC) del realm para
solicitar la acreditación que usará para hablar con el Servidor de Concesión de
Acreditaciones (Ticket Granting Server, TGS) del realm. El KDC verifica la identidad del
principal y otorga la acreditación. Si esta acreditación es válida, el TGS otorga una nueva
acreditación al principal para comunicarse privadamente con un servidor S situado dentro
del realm (con una clave conocida por el principal y el servidor S).
Las principales debilidades de Kerberos son las siguientes:
x la autenticación del propio servidor Kerberos.
x Kerberos es un sistema diseñado para autentificar a usuarios finales ante diferentes
servidores, no para autentificar sistemas ante otros sistemas.
x la gran mayoría de los sistemas no disponen de un área segura para almacenar las
claves (ya que esta deben ser almacenadas en claro en el paso inicial de
obtención de una acreditación).

3.- Técnicas criptográficas
La criptología (del griego krypto y logos, estudio de lo oculto, lo escondido) es la ciencia
que trata los problemas teóricos relacionados con la seguridad en el intercambio de
mensajes en clave entre un emisor y un receptor a través de un canal de comunicaciones
(en términos informáticos, ese canal suele ser una red de computadoras). Esta ciencia está
dividida en dos grandes ramas: la criptografía, ocupada del cifrado y descifrado de
mensajes en clave, y el criptoanálisis, que trata de descifrar los mensajes en clave,
rompiendo así el criptosistema. En lo sucesivo nos centraremos más en la criptografía y los
criptosistemas para conocer el diseño elemental de algunos sistemas seguros.
a c a
E(k,a) D(k’,a)
k k'
Modelo de criptosistema
El emisor emite un texto en claro, que es tratado por un cifrador con la ayuda de una
cierta clave, k, creando un texto cifrado (criptograma). Este criptograma llega al
descifrador a través de un canal de comunicaciones (como hemos dicho antes, para
nosotros este canal será habitualmente algún tipo de red). El descifrador convierte el
criptograma de nuevo en texto claro, apoyándose ahora en otra clave, k´(veremos más
adelante que esta clave puede o no ser la misma que la utilizada para cifrar), y este texto
claro ha de coincidir con el emitido inicialmente para que se cumplan los principios
básicos de la criptografía moderna. En este hecho radica toda la importancia de los
criptosistemas.
Es obvio, a la vista de lo expuesto anteriormente, que el elemento mas importante de todo
el criptosistema es el cifrador, que ha de utilizar el algoritmo de cifrado para convertir el
texto claro en un criptograma. Usualmente, para hacer esto, el cifrador depende de un
parámetro exterior,llamado clave de cifrado (o de descifrado, si hablamos del descifrador)
que es aplicado a una función matemática irreversible (al menos, computacionalmente):
no es posible invertir la función a no ser que se disponga de la clave de descifrado. De
esta forma, cualquier conocedor de la clave(y, por supuesto, de la función), será capaz
de descifrar el criptograma, y nadie que no conozca dicha clave puede ser capaz del
descifrado, aun en el caso de que se conozca la función utilizada.
El objetivo de la criptografía es el de proporcionar comunicaciones seguras (y secretas)
sobre canales inseguros. Ahora bien, la criptografía no es sinónimo de seguridad. No es
más que una herramienta que es utilizada de forma integrada por mecanismos de
complejidad variable para proporcionar no solamente servicios de seguridad, sino
también de confidencialidad.
Los primeros sistemas criptográficos utilizaban combinaciones más o menos complejas de
la técnica de rotación de los caracteres de un mensaje. La seguridad de este tipo de

sistemas se basaba en mantener secreto el algoritmo usado, y son fácilmente descifrables
usando medios estadísticos. En la actualidad sólo son utilizados por aficionados.
En medios profesionales, se usan criptosistemas. Se trata de funciones matemáticas
parametrizadas en las que los datos de entrada no se pueden obtener a partir de los de
salida salvo en plazos tan largos que cualquier información obtenida ya no tiene valor. La
seguridad se basa ahora, no en mantener secreto el algoritmo, que generalmente es
público, sino los parámetros (claves) del mismo.
La gran clasificación de los criptosistemas se hace en función de la disponibilidad de la
clave de cifrado/descifrado. Existen, por tanto, dos grandes grupos de criptosistemas:
3.1 Algoritmos simétricos

Los algoritmos de clave única, privada o algoritmos simétricos usan una misma clave k que
es conocida por el remitente de los mensajes y por el receptor, y mediante la cual se cifra
y descifra el mensaje que se quiere proteger.
Los cifradores simétricos pueden dividirse en dos grupos:
x cifradores de flujo, los cuales cifran un único bit del texto en claro cada vez.
x cifradores de bloque, que toman un grupo de bits (un valor típico es 64 bits) y lo
cifran como si se tratase de una unidad.
Las ventajas de la utilización criptografía de clave simétrica es la existencia de algoritmos
muy rápidos y eficientes, especialmente si se implementan en hardware. Si k es lo bastante
larga (típicamente se usan valores de 56 a 128 bits), es imposible reventarlas usando la
fuerza bruta.
En los algoritmos simétricos existe al menos una clave de cifrado/descifrado entre cada
par de usuarios de un sistema. Esto haría inviable la existencia de criptosistemas simétricos
en las grandes redes de computadores de hoy en día: para un sistema de computación
con N usuarios, se precisarıan N(N¡1)/2 claves diferentes, lo cual es obviamente poco
práctico en grandes sistemas.
El principal inconveniente estriba en la necesidad de que todas las partes conozcan k.
Esta clave es distribuida mediante una transacción separada y diferente a la transmisión
del mensaje cifrado. Es aquí, precisamente, donde se halla el punto vulnerable del
mecanismo: la distribución de la clave. Si la clave es interceptada se pone en peligro todo
el mecanismo. La clave debe ser transmitida por un canal seguro para poder asegurar la
eficacia del sistema criptográfico.
3.1.1 DES
DES (Data Encryption Standard) es desde 1977 de uso obligatorio en el cifrado de
informaciones gubernamentales no clasificadas en EEUU (anunciado por el National
Bureau of Standards, USA). Este criptosistema fue desarrollado por IBM como una variación
de un criptosistema anterior, Lucifer, y posteriormente, tras algunas comprobaciones
llevadas a cabo por la NSA estadounidense, paso a transformarse en el que hoy
conocemos como DES.
DES es un sistema de clave privada tanto de cifrado como de descifrado. Posee una clave
de entrada con una longitud de 64 bits, produciendo una salida también de 64 bits, con
una clave de 56 bits (el octavo bit de cada byte es de paridad), llamada clave externa,
en la que reside toda la seguridad del criptosistema ya que el algoritmo es de dominio
publico. Cada trozo de 64 bits de los datos se desordena según un esquema fijo a partir de
una permutación inicial conocida como IP. A continuación, se divide cada uno de los
trozos en dos mitades de 32 bits, que se someten a un algoritmo durante 16 iteraciones.

Este algoritmo básico que se repite 16 veces (llamadas vueltas), utiliza en cada una de
ellas 48 de los 56 bits de la clave (estos 48 bits se denominan clave interna, diferente en
cada vuelta). Estas claves internas se utilizan en un orden para cifrar texto(llamémoslas K1,
K2,...,K16) y en el orden inverso (K16,..., K1) para descifrarlo. En cada una de las vueltas se
realizan permutaciones, sustituciones no lineales (que constituyen en sí el núcleo del
algoritmo DES) y operaciones lógicas básicas, como la XOR.
Este criptosistema puede ser implementado tanto en software como en chips con
tecnología VLSI (Very Large Scale Integration), alcanzando en hardware una velocidad de
hasta 50 Mbps. Un ejemplo de implantación hard puede ser PC-Encryptor, de Eracom, y un
ejemplo de implantación en software es DES-LOCK, de la empresa Oceanics.
Parece claro que con las actuales computadoras y su elevada potencia de cálculo, una
clave de 56 bits (en la que reside toda la seguridad del DES) es fácilmente vulnerable
frente a un ataque exhaustivo en el que se prueben combinaciones de esos 56 bits.
3.1.2 DES Múltiple

Consiste en aplicar varias veces el algoritmo DES con diferentes claves al mensaje original.
Se puede hacer ya que DES no presenta estructura de grupo. El más común de todos ellos
es el Triple-DES, que utiliza dos claves y tres ejecuciones del algoritmo, y responde a la
siguiente estructura: codificamos con la subclave k1, decodificamos con k2 y volvemos a
codificar con k1. La clave resultante es la concatenación de k1 y k2, con una longitud de
112 bits.
3.1.3 RC-2 y RC-4

RC-2 y RC-4 fueron desarrollados por Ron Rivest, uno de los coautores del algoritmo RSA ,
en 1989 y 1987, respectivamente. Durante varios años, se ha tratado de algoritmos con
propietario y sus detalles no fueron hechos públicos. De este modo, su seguridad se
basaba en el prestigio de su autor y en el respaldo que les daba RSA Data Security, Inc.,
para las que los desarrolló. Sin embargo, en 1994 RC4 fue sometido a ingeniería inversa y
los resultados publicados en Internet. Las pruebas hechas a dicho diseño se ajustan a los
resultados esperados por lo que es razonable pensar que el diseño publicado es correcto.
RC2 fue finalmente publicado como Internet Draft en 1997.
RC-2 es un cifrador de bloque con una longitud de clave variable. Tiene definido los
mismos modos que DES y, con una clave de 64 bits, su implementación en software es dos
o tres veces más rápida que la de DES.
RC-4, al igual que RC-2, tiene una longitud de clave variable. Sin embargo, se trata de un
cifrador de flujo.
Como el resto de productos criptográficos desarrollados en EE.UU., las restricciones a su
exportación son muy fuertes. RC-2 y RC-4 tienen un estatus especial que facilita la
concesión de licencias de exportación de productos basados en ellos, pero limitando la
longitud de su clave a 40 bits. RC-4 y RC2 se usan en centenares de productos
comerciales. El protocolo SSL también los usa.
3.1.4 IDEA
Xuejia Lai y James Massey, dos prestigiosos criptógrafos, desarrollaron en Suiza en 1992 el
algoritmo IDEA (International Data Encryption Algorithm), compatible con DES (para
aprovechar el gran número de equipos que utilizan este último).
Se trata de un algoritmo iterativo que trabaja sobre bloques de 64 bits utilizando claves de
128 bits. El proceso de cifrado consta de ocho fases idénticas en la que lo único que varía
es el sub-bloque de clave utilizado, terminando el cifrado con una transformación de la

salida. En cada paso se utilizan tres operaciones: suma bit a bit, multiplicación bit a bit y OR
exclusivo. IDEA es un algoritmo robusto por la clave de 128 bits que utiliza el cifrador de
bloques y por las complejas operaciones utilizadas para evitar el éxito de un posible
atacante, que van desde técnicas de difusión hasta adiciones módulo 2^16.
Para muchos constituye el algoritmo simétrico más seguro disponible en la actualidad.
Trabaja con bloques de 64 bits de longitud y emplea una clave de 128 bits. Como en el
caso de DES, se usa el mismo algoritmo tanto para cifrar como para descifrar.
El algoritmo IDEA se usa ampliamente en diversas aplicaciones informáticas orientadas a la
seguridad de los datos; numerosos programas destinados a trabajar en red lo utilizan ya
como el principal algoritmo de cifrado.
3.1.5 Rijndael o AES

La palabra Rijndael es un acrónimo formado por los nombres de sus dos autores, los belgas
Joan Daemen y Vincent Rijmen. Este algoritmo se denomina también AES al ser el
algoritmo ganador del concurso para el sucesor de DES en la Administración
Estadounidense.
Su interés radica en que todo el proceso de selección, revisión y estudio tanto de este
algoritmo como de los restantes candidatos, se ha efectuado de forma pública y abierta,
por lo que, prácticamente por primera vez, toda la comunidad criptográfica mundial ha
participado en su análisis.
AES es un sistema de cifrado por bloques, diseñado para manejar longitudes de clave y de
bloque variables, ambas comprendidas entre los 128 y los 256 bits. Realiza varias de sus
operaciones internas a nivel de byte. El resto de operaciones se efectúan en términos de
registros de 32 bits. Sin embargo, en algunos casos, una secuencia de 32 bits se toma
como un polinomio de grado inferior a 4, cuyos coeficientes son a su vez polinomios.
3.1.6 Otros algoritmos

Otros algoritmos basados en clave simétrica son SkipJack, que utiliza claves de 80 bits para
cifrar mensajes en bloques de 64 bits (sólo implementado en hardware) y que constituye la
base del controvertido chip Clipper; FEAL, SAFER o Blowfish (diseñado por Bruce Schneier).
3.2 Algoritmos asimétricos

También llamados algoritmos de clave pública, fueron introducidos por Whitfield Diffie y
Martin Hellman a mediados de los años 70. Su novedad fundamental con respecto a la
criptografía simétrica es que las claves no son únicas, sino que forman pares. Diffie y
Hellman demostraron la posibilidad de construir sistemas criptográficos que no precisaban
la transferencia de una clave secreta entre emisor y receptor, evitando así los problemas
derivados de la búsqueda de canales seguros para tal transferencia.
Como ya hemos señalado anteriormente, el principal problema que presenta el uso
práctico de la criptografía de clave simétrica es la distribución de las claves. La
criptografía de clave asimétrica o pública, sin embargo, usa claves diferentes para cifrar y
descifrar un mensaje. Lo único que se transmite de un usuario a otro es el mensaje cifrado.
En los algoritmos asimétricos la clave de cifrado se hace de conocimiento general (se
7denomina clave pública). Sin embargo, no ocurre lo mismo con la clave de descifrado
(clave privada), que se ha de mantener en secreto. Ambas claves no son independientes,
pero del conocimiento de la pública no es posible deducir la privada sin ningún otro dato
(recordemos que en los sistemas de clave privada sucedía lo contrario). Tenemos pues un
par clave pública-clave privada; la existencia de ambas claves diferentes, para cifrar o
descifrar, hace que también se conozca a estos criptosistemas como asimétricos.

Los algoritmos asimétricos emplean generalmente longitudes de clave mucho mayores
que los simétricos. Por ejemplo, mientras que para algoritmos simétricos se considera
segura una clave de 128 bits, para algoritmos asimétricos (si exceptuamos aquellos
basados en curvas elípticas) se recomiendan claves de al menos 1024 bits. Además, la
complejidad de cálculo que comportan estos últimos los hace considerablemente más
lentos que los algoritmos de cifrado simétricos. En la práctica los métodos asimétricos se
emplean únicamente para codificar la clave de sesión (simétrica) de cada mensaje o
transacción particular.
La criptografía de clave asimétrica posee dos inconvenientes:
x el primero se refiere a la velocidad. Los sistemas basados en clave asimétrica son
notablemente más lentos que sus equivalentes de clave simétrica (por lo general y
como mínimo, unos dos órdenes de magnitud). Por tanto estos sistemas no suelen
ser adecuados para el cifrado masivo de datos.
x el segundo está relacionado con la validación de la clave. La discusión sobre la
fortaleza de un algoritmo de clave asimétrica es irrelevante sin una discusión previa
sobre el protocolo de validación de las claves.
3.2.1 RSA
Este sistema de clave publica fue diseñado en 1977 por los profesores del MIT
(Massachusetts Institute of Technology) Ronald R. Rivest, Adi Shamir y Leonard M. Adleman.
La seguridad de RSA radica en la dificultad de la factorización de números grandes: es
fácil saber si un numero es primo, pero es extremadamente difícil obtener la factorización
en números primos de un entero elevado, debido no a la dificultad de los algoritmos
existentes, sino al consumo de recursos físicos (memoria, necesidades hardware y tiempo
de ejecución) de tales algoritmos.
RSA se basa en la dificultad para factorizar grandes números. Las claves pública y privada
se calculan a partir de un número que se obtiene como producto de dos primos grandes.
El atacante se enfrentará, si quiere recuperar un texto claro a partir del criptograma y la
llave pública, a un problema de factorización.
Si un usuario A desea enviar información cifrada, ha de elegir aleatoriamente dos números
primos grandes (del orden de cien dígitos), p y q. Estos números se han de mantener en
secreto. La resolución de congruencias necesarias para descifrar el mensaje es
algorítmicamente inviable sin ninguna información adicional, debido al elevado tiempo de
ejecución del algoritmo.
3.2.2 El Gamal
El algoritmo ElGamal (también conocido como algoritmo Diffie-Hellman, variante ElGamal)
se basa en la dificultad de calcular algoritmos discretos en un campo finito.
Durante 1984 y 1985 ElGamal desarrolló un nuevo criptosistema de clave pública basado
en la intratabilidad computacional del problema del logaritmo discreto: obtener el valor
de x a partir de la expresión
y { ax (mod p)
es, como hemos comentado para RSA, computacionalmente intratable por norma
general.

3.2.3 Estándares de criptografía de clave pública PKCS
Los Estándares Criptográficos de Clave Pública (PKCS, Public Key Cryptography Standards)
son un intento por parte de la empresa RSA Data Security, Inc. de proporcionar una norma
para la industria que permita una interfaz estándar con la criptografía de clave pública. A
diferencia de otros estándares, respaldados por organismos internacionales, se trata de
una norma ad hoc creada por una única empresa. A pesar de que en el desarrollo de
estos estándares han participado muchas otras empresas, RSA Inc. se reserva la última
palabra en su promulgación y revisión.
Aunque no son realmente estándares, son una aproximación como otra cualquiera al
mundo de la criptografía, con la ventaja de que los soportan múltiples fabricantes. En la
actualidad se trata de doce normas:
x PKCS#1 (RSA Encryption Standard) describe un método para la utilización del
algoritmo RSA. Su propósito es producir firmas digitales de mensajes y “envoltorios
digitales” (mensajes cifrados) utilizando la sintaxis definida en el estándar PKCS#7.
Las firmas digitales se producen aplicando una función de hash al mensaje y
cifrando la huella digital resultante con la clave privada del firmante. El mensaje y
su firma digital se representan tal como indica PKCS#7. Para conseguir los
envoltorios digitales, el mensaje se cifra primero con una clave simétrica y, después,
se cifra dicha clave con la clave pública del destinatario del mensaje. Ambos
componentes (sobre y clave cifrada) se representan juntos según PKCS#7. También
describe una sintaxis, idéntica a X.509 para las claves públicas y privadas y tres
algoritmos de firmado digital (MD2 y RSA, MD4 y RSA y MD5 y RSA).
x PKCS#2 y PKCS#4 han sido incorporadas a PKCS#1.
x PKCS#3 (Diffie-Hellman Key-Agreement Standard) describe un método para
implementar el intercambio de claves Diffie-Hellman.
x PKCS#5 (Password-Based Encryption Standard) describe un método para cifrar
mensajes con una clave secreta derivada de una frase de paso. Su objetivo
primario es permitir la transmisión cifrada de claves privadas entre dos ordenadores,
como se describe en el PKCS#8, aunque puede ser usada para cifrar mensajes.
Emplea MD2 o MD5 para producir una clave a partir de una frase de paso. Esta
clave se utiliza para cifrar con DES (en modo CBC) el mensaje en cuestión.
x PKCS#6 (Extended-Certificate Syntax Standard) describe una sintaxis para
“certificados extendidos”, entendiendo por tales un superconjunto de X.509, de
modo que se pueden extraer certificados X.509 de estos certificados. Se incluyen
atributos adicionales como puede ser la dirección electrónica. Una lista no
exhaustiva de tales atributos se define en PKCS#9.
x PKSC#7 (Cryptographic Message Syntax Standard) es una sintaxis general para
datos que pueden tener alguna operación criptográfica asociada, ya sea cifrado
(“envoltorios o sobres digitales”) o firmado (firmas digitales). La sintaxis es recursiva,
de modo que se pueden anidar envoltorios digitales o cifrar datos cifrados
previamente. También se permiten atributos adicionales, como marcas temporales
(time stamps)... Una forma límite de utilización de esta sintaxis proporciona un
método para distribuir certificados o listas de revocación de certificados. En este
sentido, PKCS#7 es compatible con varias arquitecturas de gestión de claves
basadas en certificados.
x PKCS#8 (Private-Key Information Syntax Standard) describe una sintaxis para la
información de la clave privada, la cual incluye una clave privada y una serie de
atributos, y una sintaxis para claves privadas cifradas (un algoritmo de cifrado
basado en palabras de paso, como el descrito en el PKCS#5, podría ser usado
para cifrar la información de clave privada). Una lista parcial de atributos puede
encontrarse en PKCS#9.

x PKCS#9 (Selected Attribute Types) define algunos atributos para su uso en los
certificados extendidos del PKCS#6, los mensajes firmados digitalmente de PKCS#7,
la información de clave privada de PKCS#8 y para las peticiones de firmado de
certificados definidas en PKCS#10.
x PKCS#10 (Certification Request Syntax Standard) describe una sintaxis para las
peticiones de certificados. Una petición de certificados consiste en un nombre
distinguido (distinguished name), una clave pública y una serie de atributos
opcionales (parcialmente definidas en PKCS#9), todo ello firmado colectivamente
con la clave privada de la persona que hace la petición. Las peticiones se envía a
una Autoridad de Certificación, la cual transforma la petición en un certificado
X.509 v.3 o en un certificado extendido (PKCS#6). Las autoridades de certificación
pueden precisar procedimientos de petición no electrónicos y responder no
electrónicamente. Estos procedimientos son específicos de cada autoridad y están
fuera del estándar.
x PKCS#11 (Cryptographic Token Interface Standard) especifica una interfaz de
programación llamada Cryptoki para su uso con dispositivos criptográficos de
cualquier tipo (conocidos como tokens, tarjetas generalmente). Cryptoki tiene un
enfoque basado en objetos permitiendo que aplicaciones realicen operaciones
criptográficas sin conocer los detalles de la tecnología de los dispositivos. También
define conjuntos de algoritmos que el token puede soportar.
x PKCS#12 (Personal Information Exchange Syntax Standard) describe la sintaxis para
almacenar en software las claves públicas de un usuario, proteger sus claves
privadas, certificados y cualquier otra información de relevancia criptográfica. Su
propósito es permitir el uso de un único fichero de claves accesible por cualquier
aplicación.
x PKCS#13 (Elliptic Curve Cryptography Standard) describe, de modo similar a como
lo hace PKCS#1, un método para la utilización de algoritmos de curva elíptica.
Describe la generación y validación de parámetros, la generación y validación de
claves, el procedimiento de firmado y de cifrado...
x PKCS#15 (Smart Card File Format). Este PKCS surge para cubrir ciertos aspectos no
contemplados por PKCS#11. Para ello, trata de uniformizar la estructura de
directorios y ficheros de las tarjetas inteligentes, el contenido de ciertos ficheros
(como el de certificados) y el modo de acceder a ellos, de modo que se asegure
la interoperabilidad entre aplicaciones, para que no dependan de la tarjeta
instalada.
3.3 Sistemas híbridos

Dado que los algoritmos criptográficos de clave pública (como el ya citado RSA) son
excesivamente lentos, se han desarrollado sistemas híbridos que utilizan criptografía de
clave simétrica y de clave pública. El mecanismo, a grandes rasgos, es el siguiente:
1. A genera una clave aleatoria que servirá de clave a un algoritmo simétrico (por
ejemplo, DES).
2. Esta clave es cifrada con la clave pública de B y enviada (criptografía de clave
asimétrica).
3. B recibe el mensaje y, con su clave privada, procede a descifrar el mensaje,
obteniéndose la clave para el algoritmo simétrico.
4. El resto de comunicaciones entre A y B se lleva a cabo usando algoritmos simétricos
con la clave transmitida.

Con estos métodos híbridos se eliminan los problemas que origina la distribución de claves.
Ahora bien, aparecen problemas nuevos, debidos fundamentalmente a la posibilidad de
suplantación de alguno de los interlocutores. Esto solamente puede evitarse
intercambiando certificados en lugar únicamente de claves cifradas.
El algoritmo de intercambio de claves Diffie-Hellman permite que dos usuarios
intercambien una clave a través de un medio inseguro (como pueda ser Internet).
4.- Criptoanálisis
El criptoanálisis es la ciencia opuesta a la criptografía ya que si ésta trata principalmente
de crear y analizar criptosistemas seguros, la primera intenta romper esos sistemas,
demostrando su vulnerabilidad; es decir, trata de descifrar los criptogramas. El termino
descifrar es conseguir el texto en claro a partir de un criptograma.
En el análisis para establecer las posibles debilidades de un sistema de cifrado, se han de
asumir las denominadas condiciones del peor caso: (1) el criptoanalista tiene acceso
completo al algoritmo de encriptación, (2) el criptoanalista tiene una cantidad
considerable de texto cifrado, y (3) el criptoanalista conoce el texto en claro de parte de
ese texto cifrado. También se asume generalmente el Principio de Kerckhoffs, que
establece que la seguridad del cifrado ha de residir exclusivamente en el secreto de la
clave, y no en el mecanismo de cifrado.
Aunque para validar la robustez de un criptosistema normalmente se suponen todas las
condiciones del peor caso, existen ataques más específicos, en los que no se cumplen
todas estas condiciones.Cuando el método de ataque consiste simplemente en probar
todas y cada una de las posibles claves del espacio de claves hasta encontrar la correcta,
nos encontramos ante un ataque de fuerza bruta o ataque exhaustivo. Si el atacante
conoce el algoritmo de cifrado y solo tiene acceso al criptograma, se plantea un ataque
solo al criptograma. Un caso más favorable para el criptoanalista se produce cuando el
ataque cumple todas las condiciones del peor caso; en este caso, el criptoanálisis se
denomina de texto en claro conocido. Si además el atacante puede cifrar una cantidad
indeterminada de texto en claro al ataque se le denomina de texto en claro escogido;
este es el caso habitual de los ataques contra el sistema de verificación de usuarios
utilizado por Unix, donde un intruso consigue la tabla de contraseñas (generalmente
/etc/passwd) y se limita a realizar cifrados de textos en claro de su elección y a comparar
los resultados con las claves cifradas(a este ataque también se le llama de diccionario,
debido a que el atacante suele utilizar un fichero‘diccionario’ con los textos en claro que
va a utilizar). El caso mas favorable para un analista se produce cuando puede obtener el
texto en claro correspondiente a criptogramas de su elección; en este caso el ataque se
denomina de texto cifrado escogido.
5.- Mecanismos de firma digital

Una firma digital es un conjunto de datos asociados a un mensaje que permite asegurar la
identidad del firmante y la integridad del mensaje.
La firma digital no implica que el mensaje esté cifrado, esto es, un mensaje firmado será
legible en función de que esté o no cifrado.
El firmante generará mediante una función, un ‘resumen’ o huella digital del mensaje. Este
resumen o huella digital la cifrará con su clave privada y el resultado es lo que se
denomina firma digital, que enviará adjunta al mensaje original.

Cualquier receptor del mensaje podrá comprobar que el mensaje no fue modificado
desde su creación porque podrá generar el mismo resumen o misma huella digital
aplicando la misma función al mensaje. Además podrá comprobar su autoría, descifrando
la firma digital con la clave pública del firmante, lo que dará como resultado de nuevo el
resumen o huella digital del mensaje.
En principio, basta con cifrar un documento con la clave privada para obtener una firma
digital segura, puesto que nadie excepto el poseedor de la clave privada puede hacerlo.
Posteriormente, cualquier persona podría descifrarlo con la clave pública, demostrándose
así la identidad del firmante. En la práctica, debido a que los algoritmos de clave pública
son muy ineficaces a la hora de cifrar documentos largos, los protocolos de firma digital se
implementan junto con funciones unidireccionales de resumen (hash), de manera que en
vez de firmar un documento, se firma un resumen del mismo. Este mecanismo implica el
cifrado, mediante la clave privada del emisor, del resumen de los datos, que serán
transferidos junto con el mensaje. Éste se procesa una vez en el receptor, para verificar su
integridad. Por lo tanto, los pasos del protocolo son:
1. A genera un resumen del documento.
2. A cifra el resumen con su clave privada, firmando por tanto el documento.
3. A envía el documento junto con el resumen firmado a B.
4. B genera un resumen del documento recibido de A, usando la misma función
unidireccional de resumen. Después descifra con la clave pública de A el resumen
firmado. Si el resumen firmado coincide con el resumen que él ha generado, la
firma es válida.
De esta forma se ofrecen conjuntamente los servicios de no repudio, ya que nadie
excepto A podría haber firmado el documento, y de autenticación, ya que si el
documento viene firmado por A, podemos estar seguros de su identidad, dado que sólo él
ha podido firmarlo. En último lugar, mediante la firma digital se garantiza asimismo la
integridad del documento, ya que en caso de ser modificado, resultaría imposible hacerlo
de forma tal que se generase la misma función de resumen que había sido firmada.
5.1 Función resumen (hash)

Una función resumen o de hash H es una transformación que, tomando como entrada una
cadena x de bits de longitud variable, produce como salida una cadena h de bits de
longitud fija (h = H(x)).
5.1.1 Requisitos
Para que una función de este tipo pueda usarse con propósitos criptográficos, se debe
cumplir una serie de requisitos:
1. la entrada puede tener cualquier longitud. Deben proveerse mecanismos para
evitar el desbordamiento (overflow).
2. la salida debe ser de longitud fija, independientemente de cual fuera la longitud
de la entrada.
3. para cualquier entrada, su resumen (o valor de hash) debe ser sencillo de calcular.
4. la función resumen debe ser de un “único sentido”, entendiendo por este
concepto que, dado f(x), debe ser computacionalmente difícil encontrar un valor y
(tal vez el mismo x) tal que f(y) = f(x).
5. es difícil encontrar dos entradas x e y, tales que H(x) = H(y) (colisiones).

Al resumen o valor de hash de un mensaje M se le llama generalmente huella digital de M.
Si la salida de la función tiene una longitud de n bits, entonces existen k = 2n salidas
diferentes. Las funciones resumen son también extensivamente utilizadas como parte de
los mecanismos que generan números aleatorios.
Ejemplos de funciones resumen usadas en criptografía son MD2, MD4, MD5 o SHA.
5.1.2 Huella digital de un mensaje

Una huella digital es un conjunto de datos asociados a un mensaje que permiten asegurar
que el mensaje no fue modificado. La huella digital o resumen de un mensaje se obtiene
aplicando una función, denominada hash, a ese mensaje, esto da como resultado un
conjunto de datos singular de longitud fija. Una función hash tiene entre otras las siguientes
propiedades:
x Dos mensajes iguales producen huellas digitales iguales
x Dos mensajes parecidos producen huellas digitales completamente diferentes.
x Dos huellas digitales idénticas pueden ser el resultado de dos mensajes iguales o de
dos mensajes completamente diferentes.
x Una función hash es irreversible, no se puede deshacer, por tanto su comprobación
se realizará aplicando de nuevo la misma función hash al mensaje.
5.1.3 MD (Message Digest)

MD4 y MD5 son funciones resumen usadas en criptografía. Su nombre proviene de
Messages Digest (resumen de mensajes) y fueron diseñados por Ron Rivest. Se emplean
fundamentalmente en la generación de huellas digitales de documentos, mensajes de
correo electrónico y objetos similares. Los tres algoritmos generan huellas con una longitud
de 128 bits.
MD4 fue introducida en 1990 con el objetivo fundamental de ser una función rápida. Sin
embargo, ya en 1995 se demostró que era posible hallar colisiones para MD4 en menos de
un minuto utilizando un simple PC. Consecuentemente, MD4 ya no es considerado seguro.
MD5 es una versión mejorada (aunque algo más lenta) de MD4, desarrollada por el propio
Rivest en 1991. Su fortaleza es grande, y según su autor, Ron Rivest y dado que la longitud
de la salida es 128 bits, la probabilidad de obtener dos mensajes con el mismo resumen es
de 264, en tanto que la dificultad de obtener un mensaje cuyo resumen sea igual a uno
dado es de 2128.
Aunque se ha avanzado en su estudio y se ha demostrado que es posible hallar colisiones
para la función de compresión que utiliza el algoritmo, no se ha demostrado que puedan
hallarse para el algoritmo entero. De momento es considerado seguro, aunque se
recomienda que, “por lo que pudiera pasar”, se actualizase cualquier producto que lo
utilice a otros algoritmos como SHA-1.
Hay que destacar que estos algoritmos se encuentran en el dominio público y por tanto no
se ven afectados por problemas de patentes (como ocurre con el algoritmo RSA).
5.1.4 SHA y SHA-1

SHA (Secure Hash Algorithm) fue desarrollado en 1993 por NIST (National Institute for
Standards and Technology) junto con NSA (National Security Agency) en EE.UU. para su uso
en la norma estadounidense de firma digital, DSS (veremos el concepto de firma digital a
continuación). En 1994, el propio NIST publica una revisión de este último, conocida como
SHA-1, la cual corrige un defecto no publicado de SHA.

SHA (Secure Hash Algorithm) genera un “resumen” de 160 bits (20 bytes) a partir de
cualquier mensaje cuya longitud sea menor a 264 bits.
SHA-1 es una revisión de SHA que genera un “resumen” de 128 bits.
SHA es muy similar en su modo de operación a MD5. Utilizan como entrada mensajes de
menos de 264 bits y generan salidas de 160 bits, más largas que las producidas por
cualquier otra función resumen utilizada anteriormente. Este algoritmo es ligeramente más
lento que MD5, pero la mayor longitud del resumen del mensaje lo hace más seguro frente
a la búsqueda de colisiones usando la fuerza bruta.
5.1.5 SHS
SHS (Secure Hash Standard). Es similar a MD5 pero ligeramente más lento, aunque
presumiblemente más segura. Genera un resume de 160 bits a partir de un mensaje cuya
longitud máxima es de 2^64 bits.
5.2 Certificación de claves
5.2.1 Autoridades de certificación

Una Autoridad de Certificación (AC, en inglés CA Certification Authority) es una entidad
de confianza del emisor y del receptor del mensaje. Esta confianza de ambos en una
'tercera parte confiable' permite que cualquiera de los dos confíe a su vez en los
documentos firmados por la Autoridad de Certificación, en particular, en los documentos
que identifican cada clave pública con su propietario correspondiente y se denominan
certificados.
A modo de ejemplo citaremos las siguientes autoridades de certificación: Verisign
(http://www.verisign.com) y Thawte (http://www.thawte.com) fuera de nuestras fronteras,
ACE (http://www.ace.es) e IPS (http://www.ips.es) en España. Estas son una especie de
"agencias notariales electrónicas" que certifican claves bajo pago. También existen AC sin
ánimo de lucro, básicamente con fines de investigación o académicos, como la AC
experimental de RedIris http://ca-tic.iec.csic.es . Estas AC están pensadas para certificar
claves públicas en una conexión segura mediante navegador. Sus claves públicas
(necesarias para que nuestro navegador pueda verificar los certificados emitidos por estas
AC) se pueden descargar de la red, para lo cual hay que ir a la página web de dicha AC;
algunas de estas claves públicas ya se encuentran en su navegador, ya que fueron
entregadas por la AC directamente al fabricante. Los usuarios de Netscape Navigator, por
ejemplo, pueden ver dichas claves en Seguridad/Certificados/Firmantes. Y ya que están,
puden ver los algoritmos de cifrado simétrico que dicho navegador utiliza (Seguridad/
Navigator/ Configurar SSL v3). En España la firma electrónica se ha usado a nivel oficial
para, por ejemplo, rellenar la declaración de la Renta por Internet. Esto se hizo por primera
vez en 1.999 dentro del marco del proyecto CERES de la Fábrica Nacional de Moneda y
Timbre (FNMT), que fue la entidad que actuó como AC (http://www.cert.fnmt.es).
Una Autoridad de Registro (AR, en inglés RA) es una entidad que identifica de forma
inequívoca al solicitante de un certificado. La Autoridad de Registro suministra a la
Autoridad de Certificación los datos verificados del solicitante a fin de que la Autoridad de
Certificación emita el correspondiente certificado.
5.2.2 Certificado digital

Un certificado en un documento emitido y firmado por la Autoridad de Certificación que
identifica una clave pública con su propietario. Cada certificado está identificado por un
número de serie único y tiene un periodo de validez.

Un certificado raíz es un certificado emitido por la Autoridad de Certificación para si
misma. En este certificado consta la clave pública de la Autoridad de Certificación y por
tanto será necesario para comprobar la autenticidad de cualquier certificado emitido por
ella. Es el certificado origen de la cadena de confianza.
6.- Intrusiones
6.1 Tipos de ataques

Existen distintas técnicas que son utilizadas para los ataques contra sistemas que permitan
el acceso a la información contenida en ellos.
– Técnicas de enmascaramiento
Un usuario se hace pasar por otro para obtener información que permita acceder a un
sistema con mayores privilegios.
– Técnicas de alteración de contenidos de los mensajes
Una porción de un mensaje legítimo se altera, o bien el mensaje se retrasa o reordena
para obtener un efecto distinto al inicialmente autorizado.
– Técnicas de Repetición
Consisten en la captura pasiva de datos y su rastreo con retransmisión posterior para
producir un efecto no autorizado.
– Monitorizaciones de las transmisiones
Consiste en el rastreo de las transmisiones para obtener una información concreta.
– Técnicas de Repudio
Una persona u organismo rechaza la posibilidad de haber realizado una transacción o
enviado una información, por ejemplo alguien realiza el envío de un documento
donde se han presentado datos de declaración de renta fiscal por un valor menor al
real y si se detecta por la autoridad Tributaria, el autor niega haber presentado el
documento de declaración.
6.2 Sistemas de detección de intrusos IDS

Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es una herramienta
de seguridad encargada de monitorizar los eventos que ocurren en un sistema informático
en busca de intentos de intrusión.
Un intento de intrusión se define como cualquier intento de comprometer la
confidencialidad, integridad, disponibilidad o evitar los mecanismos de seguridad de una
computadora o red. Las intrusiones se pueden producir de varias formas: atacantes que
acceden a los sistemas desde Internet, usuarios autorizados del sistema que intentan ganar
privilegios adicionales para los cuales no están autorizados y usuarios autorizados que
hacen un mal uso de los privilegios que se les han asignado.
Un sistema de detección de intrusos permite a los administradores de seguridad conocer
cuándo está siendo atacada la red y les aporta información valiosa para determinar la
naturaleza de los ataques. Un IDS nos puede ayudar a conocer la amenaza existente fuera
y dentro de la organización, ayudándonos a tomar decisiones acerca de los recurso de
seguridad que deberemos emplear en nuestra red y del grado de cautela que deberemos
adoptar al redactar la política de seguridad.

Los objetivos de cualquier IDS (Intrusion Detection System) incluyen:
o Detección de ataques que se reciban desde el exterior de la organización.
o Detección de ataques que se produzcan hacia el exterior. Esto puede deberse a
usuarios malintencionados dentro de la propia organización o, más
frecuentemente, a usuarios externos que previamente han conseguido atacar una
máquina de la organización y que a continuación la aprovechan para lanzar
desde ella nuevos ataques hacia fuera.
o Monitorizar la carga del sistema. Para que un IDS sea efectivo es fundamental que
sea capaz de analizar todo el tráfico. Debido al análisis intensivo que se ha de
realizar con cada paquete cabe el riesgo de que en situaciones de tráfico elevado
el IDS no sea capaz de ‘digerirlo’ en su totalidad, con lo que un ataque podría
pasar desapercibido. El sistema debe disponer de herramientas que permitan
detectar cuando esto ocurre.
6.2.1 Clasificación de los IDS

En función de la fuente de información:
o IDSs basados en red, que analizan paquetes de red capturados del backbone de
la red o de segmentos LAN y detectan ataques capturando en modo promiscuo
o IDSs basados en host, que analizan eventos generados por los sistemas operativos o
software de aplicación en busca de señales de intrusión. Operan sobre la
información recogida desde dentro de una computadora, como pueden ser los
ficheros de auditoría del sistema operativo.
En cuanto al tipo de análisis:
o detección de abusos, que busca eventos en la actividad del sistema que
coincidan con un patrón predefinido o firma que describe un ataque conocido.
o detección de anomalías, que se centra en identificar comportamientos inusuales
en un host o una red.
Una vez se ha producido un análisis de los eventos y se ha detectado un ataque, el IDS
reacciona.
Según el tipo de respuesta:
o IDSs que implementan respuesta pasiva y se limitan a notificar las intrusiones de
forma automatizada al administrador de seguridad de la organización, de forma
que se puedan categorizar los ataques producidos.
o IDSs de respuesta activa que cuando detectan las intrusiones llevan a cabo
automáticamente una serie de acciones preestablecidas, como incrementar el
nivel de sensibilidad de los sensores o reconfigurar cortafuegos.
Como ejemplo de IDS podemos mencionar Snort, un software IDS de gran aceptación,
potente y gratuito, multiplataforma y de código abierto.
7.- Cortafuegos
Un firewall o cortafuegos es un sistema o grupo de sistemas que hace cumplir una política
de control de acceso entre dos redes. Se utiliza para para separar - en cuanto a seguridad
se refiere - una máquina o subred del resto, protegiéndola así de servicios y protocolos que
desde el exterior puedan suponer una amenaza a la seguridad. Evidentemente la forma
de aislamiento más efectiva para cualquier política de seguridad consiste en el

aislamiento físico, es decir, no tener conectada la máquina o la subred a otros equipos o a
Internet. Sin embargo, en la mayoría de organizaciones los usuarios necesitan compartir
información con el exterior.
Los componentes ó bloques constructivos del Sistema Cortafuegos pueden ser:
1. Encaminador (Router) de filtrado de paquetes (Cortafuegos a Nivel de Red)
2. Pasarela (Gateway) a Nivel de Aplicación ó Servidor Proxi
3. Pasarela (Gateway) a Nivel de Circuitos
Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes
o características de funcionamiento de un firewall; por máquina o host bastión (también se
denominan gates) se conoce a un sistema especialmente asegurado, pero en principio
vulnerable a todo tipo de ataques por estar abierto a Internet, que tiene como función ser
el punto de contacto de los usuarios de la red interna de una organización con otro tipo
de redes. El host bastión filtra tráfico de entrada y salida, y también esconde la
configuración de la red hacia fuera.
Por filtrado de paquetes entendemos la acción de denegar o permitir el flujo de tramas
entre dos redes (por ejemplo la interna, protegida con el firewall, y el resto de Internet) de
acuerdo a unas normas predefinidas; aunque el filtro más elemental puede ser un simple
router, trabajando en el nivel de red del protocolo OSI, esta actividad puede realizarse
además en un puente o en una máquina individual. El filtrado también se conoce como
screening, y a los dispositivos que lo implementan se les denomina chokes; el choke puede
ser la máquina bastión o un elemento diferente.
Un proxy es un programa (trabajando en el nivel de aplicación de OSI) que permite o
niega el acceso a una aplicación determinada entre dos redes. Los clientes proxy se
comunican sólo con los servidores proxy, que autorizan las peticiones y las envían a los
servidores reales, o las deniegan y las devuelven a quien las solicitó.
Físicamente, en casi todos los cortafuegos existen al menos un choke y una máquina
bastión, aunque también se considera firewall a un simple router filtrando paquetes, es
decir, actuando como choke; desde el punto de vista lógico, en el cortafuegos suelen
existir servidores proxy para las aplicaciones que han de atravesar el sistema, y que se
situan habitualmente en el host bastión. También se implementa en el choke un
mecanismo de filtrado de paquetes, y en alguno de los dos elementos se suele situar otro
mecanismo para poder monitorizar y detectar la actividad sospechosa.
7.1 Routers de filtrado de paquetes

Cualquier router IP utiliza reglas de filtrado para reducir la carga de la red; por ejemplo, se
descartan paquetes cuyo TTL ha llegado a cero, paquetes con un control de errores
erróneos, o simplemente tramas de broadcast. Además de estas aplicaciones, el filtrado
de paquetes se puede utilizar para implementar diferentes políticas de seguridad en una
red; el objetivo principal de todas ellas suele ser evitar el acceso no autorizado entre dos
redes, pero manteniendo intactos los accesos autorizados. Su funcionamiento es
habitualmente muy simple: se analiza la cabecera de cada paquete, y en función de una
serie de reglas establecidas de antemano la trama es bloqueada o se le permite seguir su
camino; estas reglas suelen contemplar campos como el protocolo utilizado (TCP, UDP,
ICMP...), las direcciones IP origen y destino, y el puerto TCP o UDP de origen y destino.
Además de la información de cabecera de las tramas, algunas implementaciones de
filtrado permiten especificar reglas basadas en la interfaz de entrada y salida del router
para un determinado paquete.

Si se encuentra correspondencia con una de sus reglas de filtrado de paquetes, el
paquete es enviado de acuerdo a la información en la tabla de enrutamiento. Si la regla
establece descartar el paquete, el paquete es descartado.
En general se recomienda que se filtren los siguientes servicios:
1. para evitar ataques de denegación de servicio por puertos UDP, filtrar todos los
servicios UDP que operen por debajo del puerto 900.
2. configurar el router de manera que todas las conexiones SMTP (puerto 25)
procedentes de fuera de una organización pasen a una estafeta central y desde
ésta se distribuya el correo internamente.
3. establecer filtros a nivel de router para el puerto 161 TCP/UDP (SNMP) que eviten
que se pueda obtener información sobre los dispositivos (routers, hubs, switches)
desde el exterior o incluso se gestionen los equipos en remoto.
4. para prevenir los ataques basados en bombas ICMP, se deben filtrar los paquetes
de redirección ICMP y los paquetes ICMP de destino inalcanzable. Además, y dado
que actualmente el campo de opciones de los paquetes IP apenas se utiliza, se
pueden filtrar los paquetes con encaminamiento en origen (source routed
packets). Estos paquetes indican el camino que ha de seguir el paquete, lo cual es
algo inseguro, ya que alguno de los puntos intermedios por los que pase el
paquete puede estar comprometido.
5. filtrar conexiones POP e IMAP a todos los sistemas excepto a los que deben ser
accesibles desde el exterior. Esta misma regla es aplicable a otros servicios como
WWW, SMTP, NTP, etc...).
6. para reducir el problema de IP spoofing, restringir la entrada en el interfaz externo,
no permitiendo que un paquete entre a nuestra red si tiene la dirección origen de
la red interna. De la misma forma, filtrar los paquetes salientes que tengan una
dirección origen distinta a la correspondiente a la red interna (con esto último se
evitan ataques de IP-spoofing originados desde nuestra red).
7. Para evitar que su organización sea utilizada como intermediaria en un ataque de
denegación de servicio, en la entrada al interfaz interno de la organización se
deben filtrar los bloques de paquetes con las siguientes direcciones:
o Redes Broadcast: es necesario bloquear el tráfico ICMP a las direcciones de
broadcast (bits dedicados a hosts todos a uno) y de red (bits dedicados a
hosts todos iguales a cero).
o El área local.
o Números de red privada reservados
7.2 Nivel de aplicación

Además del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones
software para reenviar o bloquear conexiones a servicios como finger, telnet o FTP; a tales
aplicaciones se les denomina servicios proxy, mientras que a la máquina donde se
ejecutan se le llama pasarela de aplicación.
El principal inconveniente que encontramos a la hora de instalar una pasarela de
aplicación es que cada servicio que deseemos ofrecer necesita su propio proxy; además
se trata de un elemento que frecuentemente es más caro que un simple filtro de
paquetes, y su rendimiento es mucho menor (por ejemplo, puede llegar a limitar el ancho
de banda efectivo de la red, si el análisis de cada trama es costoso). En el caso de
protocolos cliente-servidor (como telnet) se añade la desventaja de que necesitamos dos

pasos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas
implementaciones necesitan clientes modificados para funcionar correctamente.
7.3 Pasarela a nivel de circuitos

Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel de
circuito ( Circuit-level Gateways), sistemas capaces de redirigir conexiones (reenviando
tramas) pero que no pueden procesar o filtrar paquetes en base al protocolo utilizado; se
limitan simplemente a autenticar al usuario (a su conexión) antes de establecer el circuito
virtual entre sistemas. La principal ventaja de este tipo de pasarelas es que proveen de
servicios a un amplio rango de protocolos; no obstante, necesitan software especial que
tenga las llamadas al sistema clásicas sustituidas por funciones de librería seguras,
7.4 Arquitecturas de seguridad usando cortafuegos
7.4.1 Cortafuegos de filtrado de paquetes

Un firewall sencillo puede consistir en un dispositivo capaz de filtrar paquetes, un choke; se
trata del modelo de cortafuegos más antiguo basado simplemente en aprovechar la
capacidad de algunos routers para bloquear o filtrar paquetes en función de su protocolo,
su servicio o su dirección IP de forma que el router actúe como gateway de la subred. Los
accesos desde la red interna al exterior no bloqueados son directos (no hay necesidad de
utilizar proxies, como sucede en los cortafuegos basados en una máquina con dos tarjetas
de red), por lo que esta arquitectura es la más simple de implementar y la más utilizada en
organizaciones que no precisan grandes niveles de seguridad.
No obstante, elegir un cortafuegos tan sencillo puede no ser recomendable en ciertas

situaciones, o para organizaciones que requieren una mayor seguridad para su subred, ya
que los simples chokes presentan más desventajas que beneficios para la red protegida. El
principal problema es que no disponen de un sistema de monitorización sofisticado, por lo
que muchas veces el administrador no puede determinar si el router está siendo atacado
o si su seguridad ha sido comprometida. Además las reglas de filtrado pueden llegar a ser
complejas de establecer, y por tanto es difícil comprobar su corrección: habitualmente
sólo se comprueba a través de pruebas directas, con los problemas de seguridad que esto
puede implicar. Si a pesar de esto decidimos utilizar un router como filtro de paquetes, es
recomendable bloquear todos los servicios que no se utilicen desde el exterior
(especialmente NIS, NFS, X-Window y TFTP), así como el acceso desde máquinas no
confiables hacia nuestra subred; es también importante para la seguridad bloquear los
paquetes con encaminamiento en origen activado.
7.4.2 Dual-Homed Host

El segundo modelo de cortafuegos estaba formado por simples máquinas Unix equipadas
con dos tarjetas de red y denominadas anfitriones de dos bases, en las que una de las

tarjetas se suele conectar a la red interna a proteger, y la otra a la red externa a la
organización. En esta configuración el choke y el bastión coinciden en el mismo equipo: la
máquina Unix. El sistema Unix ha de ejecutar al menos un servidor proxy para cada uno de
los servicios que deseemos pasar a través del cortafuegos, y también es necesario que el IP
Forwarding esté deshabilitado en el equipo: aunque una máquina con dos tarjetas puede
actuar como un router, para aislar el tráfico entre la red interna y la externa es necesario
que el choke no enrute paquetes entre ellas. Todo el intercambio de datos entre las redes
se ha de realizar a través de servidores proxy situados en el host bastión, o bien
permitiendo a los usuarios conectar directamente al mismo (algo muy poco
recomendable, ya que un usuario que consiga aumentar su nivel de privilegios en el
sistema puede romper toda la protección del cortafuegos, por ejemplo reactivando el IP
Forwarding).
7.4.3 Screened Host

Un paso más en términos de seguridad de los cortafuegos es la arquitectura screened host
o choke-gate, que combina un router con un host bastión, y donde el principal nivel de
seguridad proviene del filtrado de paquetes. En la máquina bastión, único sistema
accesible desde el exterior, se ejecutan los proxies de las aplicaciones, mientras que el
choke se encarga de filtrar los paquetes que se puedan considerar peligrosos para la
seguridad de la red interna, permitiendo únicamente la comunicación con un reducido
número de servicios. Pero, ¿dónde situar el sistema bastión, en la red interna o en el exterior
del router? La mayoría de autores recomiendan situar el router entre la red exterior y el host
bastión, pero otros defienden justo lo contrario: situar el bastión en la red exterior no
provoca aparentemente una degradación de la seguridad, y además ayuda al
administrador a comprender la necesidad de un elevado nivel de fiabilidad en esta
máquina, ya que está sujeta a ataques externos y no tiene por qué ser un host fiable; de
cualquier forma, asumiremos la primera opción por considerarla mayoritaria entre los
expertos en seguridad informática. De esta forma, cuando una máquina de la red interna
desea comunicarse con el exterior ha de hacerlo a través de servidores proxy situados en
el host bastión, y los usuarios externos sólo pueden acceder a la red interna también a
través de este sistema.
7.4.4 Screened Subnet (DMZ)

La arquitectura Screened Subnet, también conocida como red perimétrica o De-
Militarized Zone (DMZ o Zona Desmilitarizada) añade un nivel de seguridad en las
arquitecturas de cortafuegos situando una subred (DMZ) entre las redes externa e interna,
de forma que se consiguen reducir los efectos de un ataque exitoso al host bastión: en los
modelos anteriores toda la seguridad se centraba en el bastión, de forma que si la
seguridad del mismo se veía comprometida, la amenaza se extendía automáticamente al
resto de la red. Como la máquina bastión es un objetivo interesante para muchos piratas,
la arquitectura DMZ intenta aislarla en una red perimétrica de forma que un intruso que
accede a esta máquina no consiga un acceso total a la subred protegida. Screened
subnet es la arquitectura más segura, pero también la más compleja; se utilizan dos
routers, denominados exterior e interior, conectados ambos a la red perimétrica.
En esta red perimétrica, que constituye el sistema cortafuegos, se incluye el host bastión y
también se podrían incluir sistemas que requieran un acceso controlado, como baterías de
módems o el servidor de correo, que serán los únicos elementos visibles desde fuera de
nuestra red. El router exterior tiene como misión bloquear el tráfico no deseado en ambos
sentidos (hacia la red perimétrica y hacia la red externa), mientras que el interior hace lo
mismo pero con el tráfico entre la red interna y la perimétrica; de esta forma, un atacante
habría de romper la seguridad de ambos routers para acceder a la red protegida. Incluso
es posible si se desean mayores niveles niveles de seguridad definir varias redes

perimétricas en serie, situando los servicios que requieran de menor fiabilidad en las redes
más externas; así, el atacante habrá de saltar por todas y cada una de ellas para acceder
a nuestros equipos. Evidentemente, si en cada red perimétrica se siguen las mismas reglas
de filtrado, niveles adicionales no proporcionan mayor seguridad.
Aunque, como hemos dicho antes, la arquitectura DMZ es la que mayores niveles de
seguridad puede proporcionar, no se trata de la panacea de los cortafuegos.
Evidentemente existen problemas relacionados con este modelo: por ejemplo, se puede
utilizar el firewall para que los servicios fiables pasen directamente sin acceder al bastión, lo
que puede dar lugar a un incumplimiento de la política de la organización. Un segundo
problema, quizás más grave, es que la mayor parte de la seguridad reside en los routers
utilizados; como hemos dicho antes las reglas de filtrado sobre estos elementos pueden ser
complicadas de configurar y comprobar, lo que puede dar lugar a errores que abran
importantes brechas de seguridad en nuestro sistema.
7.4.5 Otras arquitecturas

Algo que puede incrementar en gran medida nuestra seguridad y al mismo tiempo facilitar
la administración de los cortafuegos es utilizar un bastión diferente para cada protocolo o
servicio en lugar de uno sólo; sin embargo, esta arquitectura presenta el grave
inconveniente de la cantidad de máquinas necesarias para implementar el firewall, lo que
impide que muchas organizaciones la puedan adoptar. Una variante más barata
consistiría en utilizar un único bastión pero servidores proxy diferentes para cada servicio
ofertado. Cada día es más habitual en todo tipo de organizaciones dividir su red en
diferentes subredes; esto es especialmente aplicable en entornos de I+D o empresas
medianas, donde con frecuencia se han de conectar campus o sucursales separadas
geográficamente, edificios o laboratorios diferentes, etc. En esta situación es
recomendable incrementar los niveles de seguridad de las zonas más comprometidas (por
ejemplo, un servidor donde se almacenen expedientes o datos administrativos del
personal) insertando cortafuegos internos entre estas zonas y el resto de la red. Aparte de
incrementar la seguridad, firewalls internos son especialmente recomendables en zonas de
la red desde la que no se permite a priori la conexión con Internet, como laboratorios de
prácticas: un simple PC con Linux o FreeBSD que deniegue cualquier conexión con el
exterior del campus va a ser suficiente para evitar que los usuarios se dediquen a conectar
a páginas web o chats desde equipos no destinados a estos usos. Concretamente en el
caso de redes de universidades sería muy interesante filtrar las conexiones a IRC o a MUDs,
ya sea a nivel de aulas o laboratorios o a nivel de todo el campus, denegando en el router
de salida de la red hacia INet cualquier tráfico a los puertos 6667, 8888 y similares; aunque
realmente esto no evitaría que todos los usuarios siguieran jugando desde los equipos de la

universidad - por ejemplo a través de un servidor que disponga de conexión en otros
puertos -, sí conseguiría que la mayor parte de ellos dejara de hacerlo.

Temario Cuerpo de Gestión de Sistemas e Informática de La Admini

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Temario Cuerpo de Gestión de Sistemas e Informática de La Admini

Încărcat de

Drepturi de autor:

Formate disponibile

â

Preparación de oposiciones TIC

ISBN 84-95679-44-2 www.manuscritos.com

Temario Oposiciones TIC 1 Presentación anexo promoción interna

Los temas contenidos en este anexo son los siguientes:

Temario Oposiciones TIC 2 Presentación anexo promoción interna

Temario Oposiciones TIC 1 Tema I.II.05

Temario Oposiciones TIC 2 Tema I.II.05

Temario Oposiciones TIC 3 Tema I.II.05

2.2.2 Tags o tipos de marcas

Temario Oposiciones TIC 4 Tema I.II.05

2.2.3 Estructura de un documento HTML

Temario Oposiciones TIC 5 Tema I.II.05

<P> Este es un párrafo que será mostrado en el navegador </P>

Como se ve, el formateado de un documento HTML no es complicado aunque supone la

2.2.4 Enlaces ("links") y tipos de enlaces

Temario Oposiciones TIC 6 Tema I.II.05

2.2.5 Edición de HTML

2.2.5.1 Editores de HTML

Temario Oposiciones TIC 7 Tema I.II.05

2.2.5.2 Editores de texto preparados para escribir HTML

2.2.6 HTML 4.0

Temario Oposiciones TIC 8 Tema I.II.05

2.2.6.4 Hojas de estilo

Temario Oposiciones TIC 9 Tema I.II.05

Temario Oposiciones TIC 10 Tema I.II.05

2.2.6.9 Modificación de los elementos respecto a HTML 3.2

Temario Oposiciones TIC 11 Tema I.II.05

2.3.3 Estructura del XML

Temario Oposiciones TIC 12 Tema I.II.05

Temario Oposiciones TIC 13 Tema I.II.05

2.3.3.3.1 Xlink/ XPointer

2.4 Comparativa entre HTML y XML

Temario Oposiciones TIC 14 Tema I.II.05

Temario Oposiciones TIC 15 Tema I.II.05

2.5.1 Lenguajes derivados de XML para Web Services

2.5.1.1 UDDI. Descubrimiento de web services.

2.5.1.2 WSDL. Descripción de web services

Temario Oposiciones TIC 16 Tema I.II.05

2.5.1.3 SOAP. Empaquetado de mensajes

Temario Oposiciones TIC 17 Tema I.II.05

Temario Oposiciones TIC 18 Tema I.II.05

Temario Oposiciones TIC 19 Tema I.II.05

Temario Oposiciones TIC 1 Tema II.II.01

1.1 Principios del análisis

1.1.1 Dominio de la información

Temario Oposiciones TIC 2 Tema II.II.01

1.1.4 Visiones lógicas y físicas

1.2 Modelado de datos

1.2.1 Análisis de datos

Temario Oposiciones TIC 3 Tema II.II.01

1.2.1.2 Etapas del análisis de datos

1.2.2 Modelos de datos

1.2.2.1 Clasificación de los modelos de datos

 Elipses: atributos (campos de cada entidad).

 Rombos: relaciones entre conjuntos de entidades.

 Líneas: unen los distintos elementos.

Temario Oposiciones TIC 4 Tema II.II.01

1.2.2.2 Objetos de datos, atributos y relaciones

Temario Oposiciones TIC 5 Tema II.II.01

2.- Reglas de modelización. Validación y construcción de modelos

2.1 El modelo Entidad/Relación (MER)

2.1.1 Definiciones previas

Grado de una asociación: Número de entidades que participan en una asociación.

Elipses: atributos (campos de cada entidad).

Rombos: relaciones entre conjuntos de entidades.

Líneas: unen los distintos elementos.