Captulo 1

Abstracci
on de datos
Este texto on ierne al dise~no e implanta ion de estru turas de datos y algoritmos que
instrumenten solu iones a problemas mediante programas de omputador.
Un algoritmo es una se uen ia nita de instru iones que a omete la onse u ion de un
n. Usamos algoritmos en diversos ontextos de la vida; por ejemplo, uando preparamos
un plato de omida segun alguna re eta. La ultura nos ha in ul ado algunos \algoritmos",
ulturales, no naturales1 , para desenvolvernos so ialmente; por ejemplos, el algoritmo de
ondu ir un automovil o el algoritmo para ruzar una alle. En ambos ejemplos, el n que
se plantea es arribar a un sitio.
Segun Knuth [9, el termino \algoritmo" proviene del nombre del an estral
matemati o al-Khwarizm, de la Persia, parte del a tual Iran, region del planeta muy
amenazada de ser borrada del mapa. De al-Khwarizm tambien proviene la palabra
\algebra", dominio des ubierto por vez primera en el a tual invadido y devastado Irak.
Para la onse u ion de un n se emplean \medios". En el aso de un plato, los medios
que se utilizan son los instrumentos de o ina e ingredientes; el o inero, quien puede
interpretarse tambien omo un medio, onjuga, en un orden espe  o, los ingredientes
mediante los instrumentos. La se uen ia de eje u ion, o sea, el algoritmo, es fundamental
para onseguir el plato en uestion. Una altera ion del orden a arreara posiblemente una
altera ion sobre el sabor del plato.
Durante la prepara ion de un plato, el o inero requiere per ibir y re ordar la se uen ia
 l requiere, por ejemplo, sofrer algunos ali~nos antes de mez larlos on la
de eje u ion. E
arne. Segun la experien ia y la omplejidad, es posible que el o inero lleve notas que
memori en el estado de prepara ion; por ejemplo, anotar la hora en que omenzo a hornear.
En todo momento, on notas o sin ellas, el o inero requiere tener ons ien ia del estado
en el ual se ubi a la prepara ion respe to a su re eta. Para eso se sirve de su memoria.
En el aso de un programa, el omputador funge de o inero, el ual eje uta elmente
las re etas que se le propor ionan. El omputador es enton es un eje utor que organiza
y usa algunos medios para al anzar la solu ion de algun problema, segun alguna re eta
llamada \programa" y que re uerda estados de al ulos mediante una \memoria".
Aparte del CPU, quien funge de o inero, el omputador se vale de un medio fundamental: la memoria. De por s, la memoria en bruto es una se uen ia de eros y unos uyo
sentido lo imparte el programador en forma de \datos".
Cualquier programa que opere en un omputador puede dividirse en dos partes: la
1

En estos tiempos la ultura se onfunde on la natura.

Captulo 1. Abstracci
on de datos

se uen ia de instru iones de eje u ion y los datos. Las instru iones son resultado de
aquello que es ribimos omo odigo fuente. En o asiones, las instru iones pueden generarse durante la eje u ion del programa. Los datos representan el estado de al ulo en
algun momento del tiempo de eje u ion.
La palabra \dato" proviene del latn datum, parti ipio pasado de \do" (dar). Dato
onnota, pues, algo que fue dado en el pasado y que nos interesa re ordar; ese es el sentido
de que sea memorizado. En el aso de la programa ion, un dato re uerda una parte del
estado de eje u ion del programa.
El mnimo nivel de organiza ion de un dato es su tipo o clase. Un tipo de dato
dene un onjunto ompuesto por todos los valores que puede adquirir una instan ia del
dato.
Un tipo de dato puede onformarse por varios tipos de datos. En este aso lo tipi amos
de \dato estru turado" o \estru tura de datos". En algunos asos, los datos pueden ser
re ursivos (re urrentes2 ); es de ir, segun el tipo de dato se re urren a s mismos o entre
ellos.
Algunos ejemplos en C++ podran dar luz de este asunto.
Para representar numeros enteros se utiliza el tipo de dato int, el ual indi a que su
valor pertene e al onjunto Z. En este aso no se di e nada a er a de omo se representa
el tipo int en la memoria de un omputador; bien pudiera tratarse de 19, de 937 o de
2535301200456458802993406410049, entre innitos valores posibles.
Para representar numeros reales que pertene en a R, usamos el tipo float, mas interesante que el anterior porque traslu e parte de su implanta ion en la memoria de un
omputador uando expresa, mediante el nombre float, que la representa ion del numero
es en punto otante, es de ir, esta estru turada en tres ampos de forma similar a la
siguiente:
0

00001000

Signo Exponente

001011110010110001001010

Parte fra ional

El sentido de esta estru tura es ha er rapidamente sumas mediante ajuste del exponente
y de la parte fra ional. Aunque no ono emos el tama~no de los ampos anteriores, el
ono imiento de la estru tura y de la manera de manipularla nos alerta sobre el elebre e
inevitable error de redondeo que o urre uando trabajamos on aritmeti a otante.
Para ilustrar un dato re urrente nos valdremos del tipo hElemento de se uen ia 2i,
uya espe i a ion en C++ puede plantearse omo sigue:
hElemento de se uen ia 2i
struct Elemento
{
int dato;
Elemento * siguiente_elemento;
};
2

En espa~nol, as omo en la mayora de las lenguas roman es, existe el termino \re urrir", el ual,
segun su raz latina re urro, onnota \volver", \regresar". En ingles, la raz es la misma, pero basada
en re ursus, que signi a \vuelta", \retorno". En este texto se da preferen ia a re ursion en lugar de
re urren ia.

1.1. Especificaciones de datos

hElemento de se uen ia 2i modeliza un elemento entero pertene iente a una se uen ia.
Notemos que el atributo siguiente elemento se reere a un struct Elemento e indi a
la dire ion en memoria del siguiente elemento en la se uen ia.
Diversos intereses in iden en el dise~no de una estru tura de datos. Entre los mas
tpi os podemos desta ar: la omprension y manipula ion del programa por parte del
programador, el desempe~no y la adapta ion a un algoritmo o on epto parti ular. En el
ejemplo del tipo float hay dos ara tersti as de isivas. La primera es que las opera iones
aritmeti as son muy rapidas. De he ho, siempre toman tiempo onstante e independiente
del valor parti ular del dato. La segunda ara tersti a on ierne al espa io, es de ir,
ada dato en punto otante siempre o upa la misma antidad de espa io, uestion que no
su edera si usaramos aritmeti a arbitraria.
Para los tipos de datos que a abamos de ejempli ar (int y float) disponemos de un
fondo ultural, matemati o y de programa ion que nos permite se~nalarlos y omprenderlos sin ne esidad de detallar minu iosamente en que onsisten. Sabemos, sin tener que
indi arlo expl itamente, que existen las opera iones aritmeti as tradi ionales de suma,
resta, produ to y division, as omo que ha en y uales son sus resultados.

1.1

Especificaciones de datos

Supongamos que un o inero onsumado desea es ribir una de sus re etas para divulgarla
entre otros. En esta situa ion, segun el orpus ognitivo de su experien ia, el o inero
asume que sus le tores poseen un lenguaje omun que les fa ilitara entender las instru iones de su re eta. Por ejemplo, se requiere que el o inero y sus le tores tengan el mismo
on epto de lo que es una olla.
En el mar o de ese lenguaje omun, la re eta debe ser pre isa; no debe ontener ambiguedades que bloqueen al eje utante. Ademas, debe ser ompleta para que el eje utante
prepare plenamente el plato en uestion.
En la per ep ion del aprendiz de programa ion existe una diferen ia esen ial entre elaborar un plato de o ina y eje utar un programa. En o ina se opera sobre osas on retas
para la per ep ion humana. En programa ion, el omputador opera sobre datos on retos
en su memoria, pero abstra tos para nuestra per ep ion. Preguntemosnos; >Existe un
numero?, >existe un arreglo? En nuestra mente, un arreglo onstituye una abstra ion
que no se apta on nuestra per ep ion sensorial. En el omputador no tiene sentido la
abstra ion arreglo, pues este no entiende lo que es un numero o arreglo. En el aso de la
programa ion, as omo en otros dominios derivados de la matemati a, un \numero" o un
\arreglo" son on eptos abstra tos que onforman un lenguaje omun para omuni arlos
y permitir la onstru ion de mas on eptos.
Entre programadores, as omo en el resto de las pra ti as, es muy importante disponer
de un orpus omun, sobre la manera de abstraer, que permita la omuni a ion de manera
homogenea.
Consideremos una situa ion en la que deseemos disponer de un nuevo tipo de dato.
Planteemosnos dos lases de preguntas en el siguiente orden:
1. P1: >Cual es su n? o, di ho de otra manera, >para que puede servir?
2. P2: >Como se puede denir? >que representa el dato?

Captulo 1. Abstracci
on de datos

La primera pregunta nos indi a la lase de problema para el ual el tipo de dato se
ir uns ribe omo parte de la solu ion. Si esto no esta denido, enton es no tiene ningun
sentido onsiderar el tipo de dato. La segunda pregunta nos expresa que es el tipo de
dato, pero ese que-es depende del para que este se usa. Si tenemos laro el n, enton es
un dato se dene segun las opera iones permisibles y sus resultados.
Por ejemplo, si nos en ontramos en una situa ion en la ual requiramos al ulo de
variable ompleja, enton es es esen ial tener un tipo de dato \numero omplejo". LLamese
hComplejo 5i a este tipo y denamoslo omo una suma cr + ci i | cr , ci R, donde el
oe iente cr es llamado \parte real" y, ci \parte imaginaria"; este ultimo representa
una fra ion del numero \imaginado" 1 . Al igual que on los tipos anteriores, esta
deni ion asume que el le tor uenta on una ultura matemati a en la ual tienen sentido
los numeros omplejos.
Como opera iones estable emos la onsulta de la parte real e imaginaria, respe tivamente.
1.1.1

Tipo abstracto de dato

Hemos di ho que un tipo de dato representa un onjunto. Bajo la presun ion de una base
ultural matemati a, la ual omprende al on epto de onjunto, el tipo hComplejo 5i se
dene en torno a la no ion matemati a de numero omplejo que le brinda su omprension.
Bajo ese lenguaje, el ejemplo anterior satisfa e las preguntas P1 y P2 respe tivamente.
Si no dispusieramos del orpus matemati o de numero omplejo, enton es nos sera muy
dif il interpretar el sentido del tipo hComplejo 5i.
La matemati a, siempre y uando se haya pasado por su entrenamiento, dene un orpus ognitivo, bastante abstra to por ierto, que nos permite denir el nuevo tipo de dato.
Si nos remitimos a la deni ion de tipo de dato, enton es, segun la matemati a, denir un
tipo de dato estriba en denir un onjunto de las dos maneras que tiene la matemati a:
por extension o por omprension. Denir un onjunto por extension es muy objetivo,
pero tambien muy arduo y, en mu hos asos, imposible uando el onjunto es innito, por
ejemplo. En el aso de la programa ion, un tipo de dato se dene, paradoji amente, por
omprension mediante una forma metodologi a denominada \tipo abstra to de dato" o
\TAD", la ual, en la version de este texto, onsta de las siguientes partes:
1. Una des rip ion del n para el ual se destina el tipo de dato.
2. Un onjunto de axiomas y pre ondi iones que denen el dominio del tipo3 .
3. Una interfaz denida por todas las opera iones posibles sobre el TAD en la ual, por
ada opera ion, se establez an dos tipos de espe i a iones:
Especificaci
on sint
actica: nombre de la opera ion, tipo de resultado y nombres

y tipos de los parametros.

Especificaci
on sem
antica: des rip ion de lo que ha e la opera ion sobre el estado

del TAD.
En esta parte puede ser util indi ar axiomas, pre ondi iones y post ondi iones.

Dominio en el sentido de una fun ion matemati a.

1.1. Especificaciones de datos

Esen ial desta ar que, ono ido, entendido y a eptado el n, adquieren ompleto sentido las espe i a iones sinta ti a y semanti a de un TAD.
En este texto nos valdremos del on epto de lase de objeto para llevar a abo parte
de la espe i a ion.
1.1.2

Noci
on de clase de objeto

La palabra \objeto" proviene del latn obje tum (ob-je tum u ob-ie tum), omposi ion
de ob, que signi a sobre el (la), frente a, y je tum, que es el parti ipio pasado de ia ere,
etimo dire to de ya er y que signi a tender, e har. As pues, obje tum (obie tum) es lo
que ya e al frente, lo que es visible de una osa, su ara externa. En similar ontraste, la
palabra \sujeto", tambien proveniente del latn subje tum, uyo prejo latino sub se~nala
debajo, signi aba lo que esta debajo de la osa, o ulto, que le es interno; di ho de otro
modo, invisible en aparien ia4 .
En programa ion, as omo en otras ingenieras, lo objetivo, o sea, la ara visible, se
denomina \interfaz"; de inter-faz; es de ir, lo que esta entre la ara; lo que se ofre e al
exterior.
En el ontexto de la programa ion, una \ lase de objeto", o simplemente \ lase",
es una representa ion objetiva de un tipo abstra to de dato que dene su espe i a ion
sinta ti a. Por objetiva pretendemos de ir que solo nos referimos a las partes externas,
visibles, que tendra un objeto pertene iente a una lase dada. En el aso de un tipo de
dato, las \partes visibles" las onforman el nombre del tipo, los nombres de las opera iones,
los nombres de los parametros, los tipos de dato de los parametros y los resultados de las
opera iones, es de ir, su espe i a ion sinta ti a.
Para satisfa er la objetividad de la espe i a ion sinta ti a es ne esario a ordar un
lenguaje omun entre los programadores, pues de lo ontrario sera muy dif il interpretar
la interfaz. Un automovil, por ejemplo, tiene una interfaz de uso onsistente, entre otras
osas, de los pedales, el volante y el tablero. Para poder ondu irlo se requiere que el
ondu tor este entrenado en la utiliza ion de esa interfaz. Del mismo modo, para que
un programador omprenda una espe i a ion sinta ti a, este debe entender el lenguaje
en que se espe i a la lase o TAD. En el aso de este texto haremos espe i a iones
sinta ti as de TAD en el lenguaje C++ o en diagramas de lases UML.
En C++ , el ejemplo del TAD hComplejo 5i podra modelizarse del siguiente modo:
hComplejo 5i
struct Complejo
{
Complejo(float r, float i);
Complejo(const Complejo & c);
float & obtenga_parte_real();
float & obtenga_parte_imag();
};

Esta deni ion estable e \objetivamente" la espe i a ion sinta ti a del TAD hComplejo 5i,
la ual, aunada al lenguaje y al orpus matemati o ultural de la no ion de numero omplejo, ompleta la espe i a ion sinta ti a del TAD.
>Que su edio on la espe i a ion semanti a?, >esta ompleta la espe i a ion? Si
asumimos que el le tor de la espe i a ion del TAD hComplejo 5i ono e su matemati a
4

Estas a laratorias etimologi as fueron des ubiertas en [3.

Captulo 1. Abstracci
on de datos

inherente, enton es los nombres de las opera iones permiten omprender dire tamente que
ha e ada opera ion sin ne esidad de expli itarlo. >Existe alguna duda sobre lo que ha e la
opera ion obtenga parte real())? La respuesta depende, entre otros fa tores, del grado
de entendimiento matemati o que tenga el uestionante. Si el le tor no ono e la no ion
de numero omplejo, enton es se requerira una espe i a ion semanti a que le imparta lo
que es un omplejo.
Lo objetivo posibilita un a uerdo omun entre diferentes personas a er a de la interpreta ion de un tipo de dato. Para que este a uerdo o urra, es ne esario que las personas
en uestion \vean" o interpreten homogeneamente al objeto. Conse uentemente, la interpreta ion de un TAD depende del grado en que sus interesados ompartan el lenguaje on
que se exprese su espe i a ion.
1.1.3

Lo subjetivo de un objeto

Si tratamos a un dato en terminos objetivos, enton es, >en que onsiste tratarlo en terminos
subjetivos? Grosso modo, la respuesta es que la subjetividad de un TAD se trata durante
su espe i a ion semanti a.
Existen, basi amente, tres fuentes de subjetividad.
La vision, interpreta ion y, en onse uen ia, el sentido de un TAD, dependen de la
experien ia y ono imiento que tenga la persona que utili e el TAD. Pero esto es muy
subjetivo, pues ada quien tiene su propia experien ia, la ual no debe tratarse objetivamente. La primera fuente de subjetividad es enton es la interpreta ion del usuario
del TAD a er a de su sentido. Quienes hayan estudiado abalmente los numeros omplejos tendran una ompresion del TAD hComplejo 5i mas homogenea que quienes no lo
hayan estudiado. Para estos ultimos puede ser ne esario omplementar la espe i a ion.
En el aso del TAD hComplejo 5i es muy onveniente tener una traye toria de estudios
matemati os. >Puede un programador sin esta traye toria manejar el TAD hComplejo 5i?
Enfrentar esta pregunta revela perspe tivas ontradi torias.
En primer lugar, si el usuario del TAD hComplejo 5i a epta la interfaz, enton es, el
desarrollo de programas que usen numeros omplejos permite ganar omprension a er a
de la matemati a ompleja. Empero, este usuario, al no disponer del orpus matemati o
requerido, es mas propenso a utilizar la interfaz para un n diferente al que fue on ebido
el TAD hComplejo 5i; por ejemplo, para representar puntos en el plano artesiano. Si bien
esto puede representar un ahorro de odigo, puede a arrear tambien grandes onfusiones
entre los programadores y mantenedores.
La segunda fuente de subjetividad proviene del mismo dise~nador del TAD. El objeto
resultante depende tambien de la experien ia del dise~nador. Personas diferentes tienden
a proponer interfa es diferentes.
La ultima fuente de subjetividad se reere a la implanta ion del TAD. Distintos programadores haran implanta iones diferentes. Si bien esta es primariamente la subjetividad
que pretende es onder un TAD, puede ser esen ial onsiderarla por dos razones: el tiempo
de implanta ion y el tiempo de eje u ion.
El tiempo de desarrollo de un TAD puede ser tan extenso que omprometa un proye to.
Analogamente, el tiempo de eje u ion del programa resultante puede ser tan lento que haga
ne esario repetir la implanta ion del TAD. En ualquiera de estas situa iones puede ser
onveniente indi ar los aspe tos generales de la implanta ion.

1.1. Especificaciones de datos

En resumen, las fuentes de subjetividad se tipi an omo sigue:

1. Subjetividad de interpreta ion del usuario
2. Subjetividad de interpreta ion del dise~nador
3. Subjetividad de implanta ion
Por mas enfasis que se le haga a la orienta ion a objetos, los programadores que
se ir uns riban en desarrollos ooperativos deben estar ons ientes de estas subjetividades al momento de ha er la espe i a ion semanti a de un TAD. La idea en la espe i a ion semanti a es enton es ade uarse a la expe tativa ognitiva del grupo de personas involu radas en el desarrollo y uso de un TAD. Si aquel grupo, por instan ia, omprende la matemati a ompleja, enton es no solo es inne esario ahondar en una espe i a ion semanti a que explique la no ion de numero omplejo, sino que tambien puede
tornarse muy tedioso. En este aso, la fuente de subjetividad solo es de implanta ion, la
ual es pre isamente la subjetividad que pretende o ultar un TAD.
Por la razon anterior, la espe i a ion semanti a no es objetiva. Ahora bien, > omo
llevar a abo una espe i a ion semanti a efe tiva, es de ir, que logre el efe to de a eptarse
entendida por un grupo de programadores? Respuesta resumida: mediante un lenguaje
ade uado. Para disertar en torno a esta uestion, es apropiado imaginar omo dos interlo utores tratan la no ion de lo objetivo y subjetivo a er a de una osa de programa ion
y un TAD.
En el sentido en que lo hemos tratado, lo objetivo de la osa programada es per eptible
a la vision omun de los interlo utores, mientras que lo subjetivo les esta o ulto, al menos
a la mirada de uno de ellos, o de ambos. Por \vision", el le tor no debe asumir el
mero sentido sensorial, sino la apa idad de per ibir una osa o fenomeno mediante las
abstra iones y onstru iones intele tuales que la experien ia de los interlo utores les
permita. Como parte de la experien ia, es rti o que los interlo utores tengan destrezas
de programa ion equiparables.
Supongamos que un interlo utor A le presenta un TAD a otro B. Dos situa iones
ini iales son posibles: (1) B ve e interpreta el TAD de la misma manera que A y (2)
B no lo interpreta igual. En ualquiera de los dos asos, es esen ial que A onoz a la
opinion de B para poder determinarse ual de las dos situa iones o urre.
Cuando o urre la primera situa ion, los interlo utores tienen enton es una mirada
homogenea del TAD y la subjetividad que queda es de implanta ion, la ual, en el estadio
de dise~no, asi siempre es bueno o ultarla.
Si o urre la segunda situa ion, enton es A y B deben homogeneizar la vision e interpreta ion del TAD de forma que sus subjetividades de interpreta ion lleguen a ser
objetivas. La uni a manera hasta ahora ono ida de ha erlo es mediante el dialogo. Por
eso el lenguaje es fundamental en la espe i a ion de un TAD. Pero el lenguaje no es meramente unidire ional. A no tiene ninguna forma de orroborar si B omparte su mirada
si no es u ha la interpreta ion que tenga B a er a del TAD. Por tanto, uando se dise~na
un nuevo TAD, es esen ial que el dise~nador lo exponga ante los interesados e ini ie un
pro eso de dialogo que dure hasta que no hayan subjetividades de interpreta ion y solo
queden las de implanta ion.

Captulo 1. Abstracci
on de datos

1.1.4

8a

Un ejemplo de TAD

Experien ias adquiridas en el desarrollo de programas de dibujado permiten modelizar un

TAD, llamado hFigure 8ai, uyo n es generalizar opera iones inherentes al dibujado de
una gura sobre algun fondo de ontraste. Tal TAD es util para desarrollar programas
que hagan dibujos, y una propuesta de deni ion es omo sigue:
hFigure 8ai
struct Figure
{
hConstru tores de Figure 8bi
hObservadores de Figure 9bi
hModi adores de Figure 9 i
};
hFiguras on retas 12i
Denes:
Figure, used in hunks 8b, 9a, 12, and 15.

8b

El TAD hFigure 8ai modeliza una gura \general" que se dibujara en algun medio de
ontraste. Es \general" en el sentido de que solo abstraemos opera iones generales sobre
una gura geometri a ualquiera, es de ir, las opera iones son \generales"5 porque operan
sobre ualquier gura independientemente de su parti ularidad. Por \ ualquier gura"
pretendemos expresar que su forma, uadrati a, triangular, et etera, no nos importa, solo
nos interesa una gura omo abstra ion general para dibujar y la manera general de
operar sobre ella a traves de opera iones generales omunes a todas las guras existentes.
No se debe, y es preferible asumir que no se puede, denir una abstra ion sin ono er
el para que de tal deni ion. Por esa razon, uando dise~namos un TAD debemos asegurarnos de tener laro el n que perseguimos. En este sentido, en lo que on ierne al
TAD hFigure 8ai, el n es dibujar guras en algun medio de ontraste. Si este n no esta
laro, no tiene sentido hablar de guras y de sus opera iones.
La espe i a ion sinta ti a del TAD hFigure 8ai esta dada por su deni ion en C++ .
Una opera ion sobre una lase se denomina \metodo", termino proveniente del latn
methodus, el ual proviene del griego (meta - hodos). En este aso \meta"
onnota \fuera", \mas alla" y hodos signi a amino. \Metodo" quiere de ir, pues, un
amino ha ia el n [que esta fuera; es de ir, un amino on destino, on sentido.
Para denir la semanti a de ada opera ion, debemos denotar el TAD Point,
pues lo referen ian algunas opera iones del TAD hFigure 8ai. Supeditado al n del
TAD hFigure 8ai, un punto destina la ubi a ion de la gura al momento de su dibujado y no nos onviene, por ahora, denirla mas, pues no tenemos idea -y es por ahora
tambien preferible no tenerla- del medio en el ual se dibujaran las guras; por ejemplos,
un medio planar: papel o pantalla; o un medio tridimensional: proye tor tridimensional u
holografa. Para el primer tipo de medio el punto requiere dos oordenadas, mientras que
para el segundo tres.
Hay dos formas de onstruir una gura abstra ta expresadas por los siguientes onstru tores:
hConstru tores de Figure 8bi
(8a) 9a
Figure(const Point & point);
Figure(const Figure & figure);
5

La redundan ia es adrede.

1.1. Especificaciones de datos

Uses Figure 8a.

9a

El primer onstru tor requiere un punto; el segundo opia la gura a partir del punto
donde se en uentre otra gura.
El destru tor del TAD hFigure 8ai debe ser virtual:
hConstru tores de Figure 8bi+
(8a) 8b
virtual ~Figure();
Uses Figure 8a.

9b

pues de esa manera se garantiza la invo a ion de ualquier destru tor aso iado a una gura
parti ular.
A un metodo que no altere o modique el estado del objeto suele llamarsele \observador". En este sentido, una gura tiene un solo observador:
hObservadores de Figure 9bi
(8a) 17
const Point & get_point() const;

el ual \observa" su punto de referen ia en el plano. En C++ , el ali ador const sobre
un metodo indi a al ompilador que el metodo no altera el estado del objeto.
A un metodo que altera o modi a el estado de un objeto se le ali a de \modi ador"
o, a ve es \a tuador". Los a tuadores de una gura son los siguientes:
hModi adores de Figure 9 i
(8a)
virtual
virtual
virtual
virtual
virtual

void
void
void
void
void

draw() = 0;
move(const Point & point) = 0;
erase() = 0;
scale(const Ratio & ratio) = 0;
rotate(const Angle &angle) = 0;

Los nombres de metodos draw(), move() y erase() indi an laramente su fun ion6 .
El metodo scale() ajusta el tama~no (es ala) de una gura segun un radio dado. El
tipo Ratio espe i a una magnitud de es ala que signi a la propor ion en que la es ala
se modi a; si este es menor que uno, enton es la gura se a hi a, de lo ontrario se
agranda. Finalmente, el metodo rotate() gira o rota la gura en el medio segun un
angulo de tipo Angle.
Los hModi adores de Figure 9 i representan opera iones generales sobre una gura.
Podemos dibujarla, moverla ha ia otro punto, borrarla, es alarla segun alguna magnitud,
o rotarla segun algun angulo en radianes uyo signo indi a el sentido de rota ion. En
todos los asos tratamos on guras abstra tas, no on retas.
Al igual que on el tipo Point, en este estadio no es onveniente pensar en las implanta iones de los tipos Ratio y Angle. Solo basta on ono er su utiliza ion on objetos
de tipo Figure ir uns rita a n de dibujarlas.
Men ion parti ular mere en dos ali adores sinta ti os del C++ . El primero lo onforma el prejo reservado \virtual", el ual indi a que la opera ion puede implantarse
segun la parti ularidad de la gura; por ejemplo, un uadrado se dibuja diferente que un
r ulo. El segundo esta dado por el he ho de ini ializar la opera ion on el valor ero.
Esta es la sintaxis de C++ para denir un \metodo virtual puro", el ual, a su vez, dene
una lase abstra ta, o sea, abstra ion pura, sin ningun ara ter on reto, pues si no, la
lase no sera abstra ta. Para aprehender esta observa ion, omen emos por preguntarnos
>a ual gura se reere el TAD hFigure 8ai?. La respuesta orre ta es que no lo sabemos,
pues se trata de una lase abstra ta, no de una on reta.
6

A ondi ion de que se onoz an los terminos ingleses.

10

Captulo 1. Abstracci
on de datos

Los metodos virtuales puros tienen que implantarse en \ lases derivadas" de la

lase Figure que on retan implanta iones parti ulares de una gura abstra ta. Por ejemplo, el metodo scale() de un triangulo se implanta en una lase Triangle derivada de
Figure.
El on epto de deriva ion sera estudiado on mas detalle en la se ion x 1.2 (pagina 11).
1.1.5

El lenguaje UML

Hasta ahora nos hemos servido del lenguaje C++ para resolver la espe i a ion sinta ti a.
En efe to, en este lenguaje, y en otros orientados a objetos, su propia sintaxis indi ia
todos los aspe tos sinta ti os de interes y, si se es ogen nombres ade uados, fundamenta
los semanti os.
Hoy en da existen mu hos lenguajes orientados a objetos, uya presen ia nos di ulta uni ar miradas en espe i a iones y dise~nos. Para paliar este problema, desde
ha e mas de una de ada, un onsor io llamado OMG (Obje t Management Group)
intenta \homogeneizar" la manera de espe i ar TAD [5. Di ho lenguaje se llama
a ronimamente UML: "Unied Modeling Language" y se sirve de un medio que no
tienen todos los lenguajes y que es onsono on la idea de lo objetivo: el gra o. Un
gra o di e mas que mil palabras reza un antiguo proverbio, y UML lo honra uando se
requiere observar diferentes TAD y sus rela iones.
El TAD hFigure 8ai puede modelizarse pi tori amente en UML omo en la gura 1.1.
Un re tangulo representa una lase on tres se iones. El nombre de la lase se en uentra
en la se ion superior. El ttulo en letra ursiva indi a que la lase es abstra ta.
Figure
-point: Point
+Figure(in point:Point)
+Figure(in figure:Figure)
+~Figure()
+get_point(): Point
+draw(): void
+move(in p:Point): void
+erase(): void
+scale(in ratio:Ratio): void
+rotate(in angle:Angle): void

Figura 1.1: Diagrama UML de la lase Figure

La segunda se ion indi a los atributos y la ter era los metodos u opera iones. El
prejo \-" en ada nombre de atributo u opera ion indi a que el miembro es ina esible,
mientras que el smbolo \+" indi a que es ompletamente a esible.
Un nombre de opera ion en letra ursiva indi a que la opera ion es virtual o polimorfa;
on epto que estudiaremos prontamente.
Los nombres de tipos de retorno y de parametros se separan de los nombres de fun ion
y de parametros on dos puntos (a la antigua, pero elegante, usanza del Pas al y Algol).
Los parametros tienen un prejo ali ador que pueden tener valores in, out o inout para
espe i ar parametros de entrada, salida o entrada/salida respe tivamente.

1.2. Herencia

11

Un programa omplejo ontiene mu hos tipos abstra tos. Cuando esta antidad es
grande, ualquier lenguaje resulta ompli ado para mirar en unidad al sistema y dentro
de el observar sus tipos de datos e interrela iones. La gran ventaja de UML es su ara ter
gra o, el ual fa ilita observar, solo visual y objetivamente, los tipos abstra tos en una
sola mirada.
En este texto usaremos UML solo para espe i ar diagramas de lases e interrela iones
entre ellas. UML es un lenguaje de modelado mu ho mas ri o y la experien ia ha demostrado que para ganar homogeneidad de interpreta ion en un proye to, este es mas
simple que un lenguaje de programa ion.

1.2

Herencia

El TAD hFigure 8ai modeliza una gura general que no indi a nada a er a de su forma
on reta. Sin embargo, al momento de dibujar una gura se tiene que on retar y ono er
de ual gura se trata. En la jerga a objetos, a \ on retar" se le di e \espe ializar" y se
representa mediante una rela ion llamada \heren ia de lase". En UML, on retar algunas
\guras" bajo un diagrama UML, resumido, ejemplariza el on epto de una forma que nos
permite visualizar las lases y sus rela iones en una espe ie de \genealoga" o \taxonoma",
tal omo se ilustra en la gura 1.2.
Figure
-point: Point
+Figure(in point:Point)
+Figure(in figure:Figure)
+~Figure()
+get_point(): Point
+draw(): void
+move(in p:Point): void
+erase(): void
+scale(in ratio:Ratio): void
+rotate(in angle:Angle): void

Triangle
-hypotenuse: float
-angle_hypotenuse: float
+get_hypotenuse(): float
+get_angle_hypotenuse(): float
+...()

Square

Circle

-side_size: float

-ratio: float

+get_side_size(): float
+...()

+get_ratio(): float
+...()

Figura 1.2: Jerarqua de lases espe ializadas de la lase Figure

La rela ion de heren ia se expresa en UML mediante una e ha ontigua que parte
desde la lase espe ializada ha ia la lase general. En el aso ejemplo, la lase general la
onforma el TAD hFigure 8ai, mientras que las lases espe ializadas on retan las guras

12

12

Captulo 1. Abstracci
on de datos

espe  as Triangle, Square y Circle, espe ializa iones de triangulo, uadrado y r ulo
respe tivamente.
La heren ia se dene enton es omo la propiedad que tiene una lase de \heredar"
el ser de otra lase .
A la lase general se le llama \ lase base" o \fundamental", mientras que la espe ializada re ibe el nombre de \ lase derivada". En el ejemplo de las guras, el TAD hFigure 8ai
es lase base de las lases derivadas Triangle, Square y Circle.
De imos tambien que la lase derivada \hereda" de la lase base en el sentido de que
hereda toda su interfaz publi a. Un triangulo, por instan ia, hereda el punto de referen ia
atribuible a todas las guras generales, es de ir, un objeto de tipo Triangle puede invo ar
al metodo get point(), pues este fue heredado del TAD hFigure 8ai.
En el diagrama UML de la gura 1.2 se apre ia que las lases derivadas poseen atributos
y metodos que no se en uentran en la lase base. Por ejemplo, la lase Circle posee un
metodo llamado get ratio() uya fun ion es observar el radio de la ir unferen ia que
representa una instan ia de objeto de tipo Circle. El atributo \ratio" tiene sentido,
segun la geometra, para la lase Circle, pero no lo tiene para las lases Triangle y
Square. Ahora bien, las tres lases derivadas de hFigure 8ai omparten el punto de
referen ia, pues son, por deriva ion, de tipo hFigure 8ai.
Lo anterior sugiere una interpreta ion de la heren ia quiza mas ri a: la rela ion \ser",
es de ir, la lase derivada, es tambien de lase base. De este modo, objetos de tipo
Triangle, Square y Circle son, tambien, de tipo Figure.
La de lara ion en C++ de la rela ion de heren ia anterior es la siguiente:
hFiguras on retas 12i
(8a)
struct Triangle : virtual public Figure { ... };
struct Square : public Figure { ... };
struct Circle : public Figure { ... };
Uses Figure 8a.

La pseudoespe i a ion de la lase Triangle indi a que es una lase abstra ta. En
efe to, notemos que, en el aso de un triangulo, segun nuestra ultura matemati a, podemos espe ializarlo aun mas segun las longitudes de sus lados.
Lo grandioso de la heren ia es la posibilidad de expresar on eptos y abstra iones
generales a traves de lases bases para luego parti ularizarlas mediante deriva iones. Esto
ofre e la posibilidad de dise~nar indu tivamente, yendo desde lo parti ular ha ia lo general, o dedu tivamente, yendo desde lo general ha ia lo parti ular. Di ho de otro modo,
yendo desde lo on reto ha ia lo abstra to o, paradoji amente, desde lo abstra to ha ia lo
on reto.
1.2.1

Tipos de herencia

La heren ia del ejemplo anterior se denomina \heren ia publi a", pues lo que es publi o
de la lase base tambien llega a ser publi o en la lase derivada.
Hay otro modo de heren ia denominado \de implanta ion" o \heren ia privada". Este
modo expresa el he ho de que la lase base se usa para implantar la, o parte de la,
lase derivada. En UML, la heren ia privada se representa mediante una e ha punteada,

1.2. Herencia

13

mientras que en C++ se ha e mediante el ali ador private omo prejo al nombre de la
lase base.
1.2.2

Multiherencia

En o asiones, una lase de objeto es, a la vez, de dos o mas lases. En el mundo a objetos,
esto puede expresarse mediante una rela ion de heren ia multiple. Es de ir, un objeto
puede heredar de dos o mas lases base. La gura 1.3 muestra una rela ion de lases que
modeliza los a tores de una universidad. Aten ion espe ial mere e la lase Preparador. En
la vida real, un preparador es un estudiante ex elso, uya ex elen ia apre ia la universidad
para la asisten ia y mejora de sus ursos. Como retribu ion, la universidad le otorga
al estudiante un estipendio. En los terminos del diagrama UML, Preparador hereda
de las lases Estudiante y Trabajador Universitario respe tivamente. De este modo
denimos que un preparador es, a la vez, estudiante y trabajador universitario.
Persona
+nombres(): Nombres
+cdula(): Cdula
+edad(): int

Trabajador Universitario
+salario(): Salario
+antiguedad(): int
+...()

Profesor

Obrero

Estudiante
+expediente(): Expediente_Estudiante
+...()

Empleado

Preparador

Figura 1.3: Rela iones de lases de personas en una universidad

Es posible tener rela iones de multiheren ia de interfaz por una parte, y de implanta ion por alguna otra.
1.2.3

Polimorfismo

La palabra polimorfo proviene del griego (\poly"), que signi a \mu ho", mientras que \morfo" proviene de (\morfe"), que signi a \gura", \forma". Polimorfo
onnota, pues, \mu has guras", \mu has formas". En la jerga a objetos, polimorfismo

14

Captulo 1. Abstracci
on de datos

es la propiedad de expresar varias funciones o procedimientos diferentes o

similares bajo el mismo nombre.

Hay tres lases de polimorsmo: de sobre arga, de heren ia y de plantilla.

1.2.3.1

Polimorfismo de sobrecarga

Sobre arga es la apa idad de un lenguaje a objetos para denir nombres iguales de fun iones, pro edimientos y metodos. Consideremos, por ejemplo, la fun ion siguiente:
const int sumar(const int & x, const int & y);

uyo n es sumar dos enteros. sumar() puede \sobre argarse" para que sume mas
enteros:
const int sumar(const int & x, const int & y, const int & z);
const int sumar(const int & w, const int & x, const int & y, const int & z);

El ompilador, a traves de la antidad de parametros, ha e la distin ion y de ide ual

de las tres fun iones es la que se debe invo ar. Por ejemplo, si el ompilador en uentra:
sumar(1, 2, 3);

Enton es este generara la llamada a sumar() on tres parametros.

Es posible tambien denir sumar() para que \sume" otra lase de objetos. Por ejemplo:
const string sumar(const string & x, const string & y);

La suma de adenas puede interpretarse omo la on atena ion. El ompilador ha e

la distin ion respe to a las versiones aritmeti as mediante los tipos de los parametros.
En C++ se pueden sobre argar los operadores. Por ejemplo, podramos espe i ar la
on atena ion de adenas del siguiente modo:
const string operator + (const string & x, const string & y);

En este aso, puede es ribirse algo as omo:

string s1, s2;
...
string s3 = s1 + s2;

La sobre arga de operadores e, in lusive, la de fun iones, es un asunto polemi o porque

o ulta opera iones y puede ontravenir el sentido ultural del operador. Por ejemplo, el
odigo anterior tiene perfe to sentido ultural para la aritmeti a, pero quiza no para la
on atena ion. Cuando en una primera inspe ion un le tor lea la suma de adenas,
posiblemente el pensara que los operandos son numeri os, lo ual, en el ultimo ejemplo,
no es el aso. Por esa razon es por lo general re omendable evitar la sobre arga.

1.2. Herencia

1.2.3.2

15

Polimorfismo de herencia

Dada una rela ion de heren ia entre tres lases X, Y y Z, expresada gra amente de la
siguiente manera:
X
+mtodo(...): T

Y
+mtodo(...): T

15

Z
+mtodo(...): T

El polimorsmo de heren ia se dene omo la posibilidad de denir (no de sobre argar)

metodos virtuales del mismo nombre en las tres lases, invo ar al metodo desde la lase X y
determinar, en tiempo de eje u ion, ual es el metodo on reto segun sea la implanta ion
real de la lase X.
A los metodos Y::metodo() y Z::metodo() se les onnota omo \espe ializa iones"
del metodo en la lase base X::metodo().
Podra de irse que el polimorsmo de heren ia es la sobre arga de metodos virtuales
entre las lases. Es importante resaltar que, en este aso, los prototipos de los metodos
virtuales tienen que ser identi os.
Re ordemos que el TAD hFigure 8ai ontiene metodos virtuales, puros, que no se
pueden implantar. Si pretendiesemos dibujar un objeto de tipo hFigure 8ai se nos apare era la pregunta: >Cual gura?, pues el TAD hFigure 8ai es una gura abstra ta, no
on reta. Es uando ono emos ual es la gura que tiene sentido indagar omo dibujarla.
La implanta ion de un metodo virtual puro se le delega a una lase derivada. Para
el aso del TAD hFigure 8ai, sus hFiguras on retas 12i deben implantar sus metodos
virtuales puros. Por ejemplo, los metodos Square::draw() y Circle::draw() implantan
de manera diferente el dibujado de su orrespondiente gura. De este modo, uando se
opera sobre un objeto general de tipo hFigure 8ai y se invo a a un metodo virtual, se
sele iona, en tiempo de eje u ion, el metodo de espe ializa ion segun la gura on reta
sobre la ual se este operando.
La virtud del polimorsmo de heren ia es que permite es ribir programas generales
que manipulen \guras" generales7 . Estos programas no requieren ono er las guras
on retas, pues operan en fun ion de metodos virtuales generales puros. Por ejemplo,
partes de programas para dibujar guras manipulan guras en abstra to, las dibujan, las
mueven, las rotan, et etera. A efe tos de e onomizar odigo resulta util la posibilidad de
es ribir programas generales omo el del ejemplo siguiente:
hManejo general de Figure 15i
void release_left_button(const Action_Mode mode, Figure & fig)
{
switch (mode)
{
case Draw:
case Move:
7

De nuevo, la redundan ia es adrede.

16

Captulo 1. Abstracci
on de datos

fig.draw(); break;
case Delete: fig.erase(); break;
case Scale: fig.scale(dif_mag_with_previous_click()); break;
case Rotate: fig.rotate(dif_angle_with_previous_click()); break;
...
}
}
Uses Figure 8a.

la ual sera invo ada en aso de que se dete tase que se suelta el boton izquierdo del raton
dentro de un \lienzo" abstra to de dibujado.
release left button() no requiere ono er la gura on reta. Su odigo es general y no se afe ta por las modi a iones o a~nadiduras de las guras. Por ejemplo,
si release left button() opera sobre un uadrado, enton es se invo aran a los metodos
virtuales \ on retos" de la lase Square; analogamente, o urre on un r ulo, aso en el
ual se invo aran los metodos de Circle.
1.2.3.3

16

Polimorfismo de plantilla (tipos parametrizados)

Hay situa iones en las uales un problema y su solu ion pueden espe i arse de forma independiente del (o los) tipo(s) de dato(s). Por ejemplo, el problema de bus ar un elemento
en un onjunto, y su solu ion, son independientes del tipo de elementos. Si suponemos
que el onjunto se representa mediante un arreglo, enton es, una posible manera, generi a,
de bus ar un elemento, es omo sigue:
hB
usqueda dentro de un arreglo 16i
template <typename T, class Compare>
int sequential_search(T * a, const T& x, int l, int r)
{
for (int i = l; i <= r; i++)
if (are_equals<T, Compare> () (a[i], x))
return i;
return No_Index;
}
Uses sequential search 170a.

Esta rutina bus a el elemento x dentro del rango omprendido entre l y r del arreglo a.
Se retorna un ndi e dentro del arreglo orrespondiente a una entrada que ontiene un
elemento igual a x, o el valor No Index (por lo general 1), si el arreglo no ontiene x.
Aparte de los parametros pertinentes al onjunto,
el algoritmo
generi o sequential search<T, Compare>() requiere dos tipos parametrizados: el
tipo de dato del onjunto, llamado generi amente T, y un tipo omparador de igualdad
llamado are equals<T, Compare>(), uyo uso sera abordado en x 1.3.1 (pagina 20).
Fun iones o metodos omo sequential search<T, Compare>() se llaman \plantillas"8 . De imos que sequential search<T, Compare>() es \generi a" porque genera
una familia de fun iones para ada tipo existente en el ual exista una lase are equals().
En otras palabras, una plantilla automatiza la sobre arga de la fun ion o lase para los
tipos involu rados en la plantilla.
8

En ingles, \template".

1.2. Herencia

17

Observemos que aunque la plantilla es la misma, o sea, es generi a, el odigo

generi o sequential search<int, are equals<int> >(...) es diferente al algoritmo
sequential search<string, are equals<string> >(...). El ompilador debe generar dos odigos distintos; uno para arreglos de enteros (int) y otro para arreglos de
adenas (string).
Cuando se ejempli o la lase hFigure 8ai se indi o que su n es dibujarla en un medio
de ontraste. >De ual medio se habla: papel, pantalla de vdeo, televisor, holografa ...?
El le tor a u ioso debe haberse per atado de que las implanta iones de la lase hFigure 8ai
(Square, Triangle y Circle) tienen que asumir un medio en donde efe tuar las opera iones. Una manera de independizarse del medio de ontraste es ha er a la lase hFigure 8ai
una plantilla uyo parametro sea, justamente, el medio de ontraste. La idea se ilustra en
el diagrama UML de la gura 1.4.
Medium_Type:Medium

Figure
-point: Point
+medium: Medium_Type
+Figure(in point:Point)
+Figure(in figure:Figure)
+~Figure()
+get_point(): Point
+draw(): void
+move(in p:Point): void
+erase(): void
+scale(in ratio:Ratio): void
+rotate(in angle:Angle): void

Figura 1.4: Diagrama UML de la lase Figure on el medio de ontraste omo parametro

17

En UML, los parametros plantilla de la lase se espe i an en un re tangulo punteado

situado en la esquina superior dere ha.
Un objeto de tipo hFigure 8ai posee omo tipo parametrizado el medio en donde
se manipulan las guras. Puede ser ne esario que las espe ializa iones de hFigure 8ai
onoz an el tipo on reto del medio de ontraste. Por esta razon, la version plantilla
de hFigure 8ai exporta el tipo parametrizado bajo el nombre Medium Type. En C++ esta
a ion se lleva a abo mediante la siguiente de lara ion:
hObservadores de Figure 9bi+
(8a) 9b
typedef Medium Medium_Type;

De esta manera, una espe ializa ion puede instan iar un objeto de tipo Medium Type omo
se ilustra en el siguiente ejemplo:
void Square::draw()
{
/* .... */
Medium_Type m; // Instancia un objeto "medio de contraste"

18

Captulo 1. Abstracci
on de datos

/* .... */
medium.put_line(...);
}

El atributo tipo medium de la lase Figure<Medium> le permite a eso a este. La espe ializa ion Square::draw() dibujara lneas en el medio de ontraste orrespondientes al
respe tivo uadrado. La implanta ion de Square::draw() deviene generi a respe to al
medio.
1.2.3.4

Lo general y lo gen
erico

Los terminos \general" y \generi o" no solo se pare en mu ho lexi amente, sino que, en
efe to, tambien son muy similares semanti a y etimologi amente.
La raz de ambos terminos es el verbo latino genero, que signi a engendrar, rear.
En esta epo a, tanto \general" omo \generi o" onnotan lo que es omun a una espe ie.
Genero proviene a la vez del griego (genus), que en el lenguaje moderno onnota
\raza" y que en griego se refera a lo omun. De \genus" proviene una muy amplia variedad
de terminos: genero, gen, geneti a, gentili io, generoso, gente, genealoga, genio, genial,
ingenio, ingeniera, et etera.
En su elebrsima y tras endental Metafsi a, Aristoteles distingue el \genero" omo lo
que le es esen ialmente omun a una espe ie. Podemos de ir, pues, que la jerga a objetos
esta, desde ha e mas de 2500 a~nos, impregnada por esta idea.
En el aso de la programa ion a objetos, \general" identi a lases de objetos generales;
es de ir, bases de otras lases mas parti ulares, individuales, o lases que operan sobre la
generalidad. Por ejemplo, la lase hFigure 8ai es general a todas las guras, mientras que
la lase are equals() representa la ompara ion general y generi a entre objetos.
\Generi o" onnota lo que genera, o sea, en la orienta ion a objetos, a las plantillas,
on epto que re ien a abamos de presentar y ejempli ar.

1.3

El problema fundamental de estructuras de datos

Existe una lase de problema uya o urren ia es tan ubi ua en pra ti amente todos los
ambitos de la programa ion, que ya es posible generizarla en una sola lase. Se trata del
onjunto. Puesto que en la mayora de los asos, los elementos son del mismo tipo, es posible objetizarlo en un TAD generi o tal omo lo ilustra el diagrama UML de la gura 1.5.
El diagrama en uestion modeliza lo que se ono e omo el \problema fundamental de estru turas de datos". Las diferentes maneras de implantarlo y sus diversas ir unstan ias
de apli a ion, abar an asi todo el orpus de este texto.
La lase Set<T, Compare> modeliza un onjunto generi o de datos de tipo T, on
riterio de ompara ion Compare, uyo n es generalizar opera iones sobre onjuntos sin
que nos interese omo estos se implantan.
Hay mu has formas de implantar el tipo Set<T, Compare>. La de ision depende de
sus ir unstan ias de uso.
Conjuntos de datos que se orrespondan on el problema fundamental se denominan
\ ontenedores". Un ontenedor es, pues, un onjunto de elementos del mismo tipo.

1.3. El problema fundamental de estructuras de datos

19

Key_Type:T
Compare_Type:Compare

Set
+insert(in key:T): void
+search(in key:T): T *
+remove(in key:T): void
+size(): size_t
+swap(inout set:Set<T, Compare>): void
+join(in set:Set<T, Compare>): Set<T>
+split(in key:T,out l:Set<T, Compare>,out r:Set<T,
Compare>): void
+position(in key:T): int
+select(in pos:int): T*
+split_pos(in pos:int,out l:Set<T, Compare>,
out r:Set<T, Compare>): void

Figura 1.5: Diagrama UML de una lase generi a onjunto (Set)

19

Set<T, Compare> puede modelizarse en C++ omo sigue:

hConjunto fundamental 19i
template <typename T, class Compare>
struct Set
{
void insert(const T & key);
T * search(const T & key);
void remove(const T & key);
const size_t size() const;
void swap(Set<T, Compare> & set);
void join(Set<T, Compare> * set);
void split(const T& key, Set<T, Compare> *& l, Set<T> *& r);
const int position(const T& key) const;
T * select(const int pos);
void split_pos(const int & pos, Set<T, Compare> *& l, Set<T, Compare> *& r);
};

En lneas generales, el problema fundamental se dene omo el mantenimiento de un

onjunto Set<T, Compare> de elementos de tipo T on las opera iones basi as de inser ion,
busqueda, supresion y ardinalidad y uyas interfa es fundamentales son insert(),
search(), remove() y size() respe tivamente.
Fre uentemente, los elementos del onjunto se llaman \ laves". De all el nombre de

20

Captulo 1. Abstracci
on de datos

parametro key en mu has de las interfa es de Set<T, Compare>.

swap(set) inter ambia todos los elementos de set on los de this. Seg
un la estru tura de datos on que se implante Set<T, Compare>, algunas ve es esta opera ion sera
muy rapida.
El metodo join(set) une this on el onjunto referen iado por el parametro set.
Despues de la opera ion, set deviene va o.
join() puede tener varia iones seg
un el tipo de onjunto y la estru tura de datos. Las
mas omunes son la on atena ion y la inter ep ion.
1.3.1

Comparaci
on general entre claves

Mu has ve es, el tipo generi o T es ordenable, es de ir, las laves pueden disponerse en
una se uen ia ordenada desde la menor hasta la mayor o vi eversa. En esos asos apare en
el resto de las opera iones y la lase de ompara ion Compare.
Compare es una lase que implanta la ompara ion entre dos elementos de tipo T.
Por lo general, Compare implanta el operador rela ional <. Con una lase de este tipo
es posible realizar el resto de los operadores rela ionales. Por ejemplo, si tenemos dos
laves k1 y k2 y una lase Compare<T> uyo operador () implanta k1 < k2, enton es el
siguiente pseudo odigo ejempli a todas las ompara iones posibles:
if (Compare() (k1, k2)) // k1 < k2?
// acci
on a ejecutar si k1 < k2
else if (Compare() (k2, k1)) // k2 < k1?
// acci
on a ejecutar si k2 < k1
else // Tienen que ser iguales
// acci
on a ejecutar si k1 == k2

1.3.2

Operaciones para conjuntos ordenables

Si el onjunto es ordenable, enton es este puede interpretarse omo una se uen ia ordenada
S =< k0 , k2 , . . . , kn1 >, en la ual n es la ardinalidad del onjunto. En ese aso, pueden
ha erse varias opera iones sobre la se uen ia S.
El metodo split(key, l, r) \parti iona" el onjunto en dos sub onjuntos
l =< k0 , k1 , . . . , ki > y r =< ki+1 , ki+2 , . . . , kn1 > seg
un la lave key tal que l < key < r.
Es de ir, l ontiene las laves menores que key y r las mayores. Despues de la opera ion,
this deviene va o.
El metodo position(key) retorna la posi ion de la lave dentro de lo que sera la
se uen ia ordenada. Si key no se en uentra en el onjunto, enton es se retorna un valor
invalido.
El metodo select(pos) retorna el elemento situado en la posi ion pos segun el orden.
Si pos es mayor o igual a la ardinalidad, enton es se genera una ex ep ion.
Finalmente, el metodo split pos(pos, l, r) \parti iona" el onjunto en
l =< k0 , k1 , . . . , kpos1 > y r =< kpos , . . . , kn1 >. Una ex ep ion o urrira si pos esta
fuera del rango.

1.4. Dise
no de datos y abstracciones

1.3.3

21

Circunstancias del problema fundamental

Cualesquieran que sean las situa iones de utiliza ion, los elementos de un onjunto tienen
que guardarse en alguna lase de memoria. La manera de representar en memoria tal
onjunto requiere de una estru tura de datos uya forma depende de sus ir unstan ias
de uso.
Hay varios fa tores que in iden en el dise~no o es ogen ia de la estru tura de datos, entre
los que abe desta ar los ono imientos que se tengan sobre la ardinalidad, la distribu ion
de referen ia de los elementos, las opera iones que se usaran y la fre uen ia on que estas
se invo aran.
La ardinalidad de ide de entrada el tipo de memoria. Una ardinalidad muy grande
requerira memoria se undaria (dis o) o ter iaria (otros medios mas lentos), y esta de ision
afe ta radi almente el tipo de estru tura de datos.
Hay o asiones en que algunas laves son mas propensas a iertas opera iones que
otras. Por ejemplo, si las laves fuesen apellidos, enton es el saber que las letras \x"
o \y" son po o fre uentes, y que las vo ales son mas fre uentes, puede in idir en una
estru tura de datos que tienda a re uperar rapidamente laves que tengan, por ejemplo,
\a" omo segunda letra.
Segun el problema, algunas opera iones son mas probables que otras; in lusive, en
mu hos asos, no se utilizan todas las opera iones o la mayora de las a tividades sobre el
onjunto se on entran en una o po as opera iones. En estos asos, la estru tura de datos
puede dise~narse para optimar la opera ion mas fre uente.
1.3.4

Presentaciones del problema fundamental

En el ambito fun ional existen varias interpreta iones del tipo generi o hConjunto fundamental 19i. Hay, en esen ia, dos onsidera iones dignas de resaltarse.
La primera onsidera ion on ierne a la repiten ia o no de los elementos. Cuando se
permite repetir los elementos de un onjunto, enton es a este se le denomina \multi onjunto".
En la bibliote a estandar C++ , en adelante llamada stdc++, al onjunto se le ono e
omo set<T, compare>, mientras que al multi onjunto omo multiset<T, compare>.
La segunda onsidera ion es el alma enamiento de pares ordenados de tipo (Key, Elem).
La idea es una tabla aso iativa que re upere una instan ia elem Elem dada una
lave key Key. A esta lase de onjunto se le ono e omo \mapeo"9 . Cuando las
laves pueden repetirse, enton es al mapeo se le di e \multimapeo".
En la bibliote a estandar C++ al mapeo se le ono e omo map<Key, Elem, compare>
mientras que al multimapeo omo multimap<Key, Elem, Compare>. En los mapeos suele
implantarse el operador [] segun la lave.

1.4

Dise
no de datos y abstracciones

El dise~no de abstra iones y sus onse uentes TAD es un arte que se aprende on la experien ia. Adquirirla no tiene otra alternativa que enfrentarse responsablemente a problemas
9

Del ingles \mapping", uya onnota ion matemati a signi a fun ion en el sentido de la teora de
onjuntos. Por otra parte, es importante desta ar que el termino fue re ientemente a eptado por la RAE.

22

Captulo 1. Abstracci
on de datos

reales de programa ion. Por responsabilidad se entiende la a titud honorable a responder

por los equvo os, lo ual no solo esta ondi ionado a la ons ien ia que el pra ti ante
tenga a er a de su ono imiento, sino a su honestidad y fuerza de ara ter.
En lo que sigue de esta se ion se plantean algunas re exiones que debe onsiderar el
aprendiz para enfrentar mejor el aprendizaje del dise~no de datos y programa ion.
1.4.1

Tipos de abstracci
on

Segun el interes que se tenga al momento de dise~nar una abstra ion o estru tura de datos,
esta puede lasi arse en \orientada ha ia los datos", \orientada ha ia el ujo" u \orientada ha ia el on epto o abstra ion".
Una abstra ion orientada ha ia los datos es aquella uyo n esta en auzado por la
organiza ion de los datos en el omputador. A la vez, tal organiza ion obede e a requerimientos de desempe~no, ahorro de espa io o algun otro que ata~na al omputador,
sistema operativo u otros programas sistema. Este es el aso de mu has de las estru turas
de datos que estudiaremos en este texto. Ejemplos de estas lases de orienta ion son los
arreglos, las listas enlazadas y las diversas estru turas de arbol que seran estudiadas en
este texto.
Mu hos problemas omputa ionales exhiben un patron de pro esamiento distintivo
y uniforme. En tales situa iones puede ser muy onveniente disponer de una estru tura de datos que represente el orden o esquema de pro esamiento de los datos. En este
aso de imos que la estru tura esta orientada ha ia el ujo o al patron. Por ejemplo, si los
datos deben pro esarse segun el orden de apari ion en el sistema, enton es una disposi ion
de los datos en una se uen ia puede representar el orden de llegada. Tal estru tura se denomina \ ola" y sera estudiada en x 2.6 (pagina 134). Notemos que en este aso no se
piensa en la organiza ion que los datos tengan en memoria, sino en el orden o patron en
que estos se pro esen.
Finalmente, el dise~no de una estru tura de datos puede fa ilitar la representa ion de un
on epto o abstra ion ono ida on miras a omprender el problema y, onsiguientemente,
desenvolverse omodamente en su solu ion. En este aso de imos que la estru tura de datos
esta orientada ha ia el on epto. La idea es simpli ar al programador o a los usuarios el
entendimiento del problema y de su solu ion.
Hay mu hos aminos para resolver problemas. Cuentan que Mi hel Faraday, pre ursor
de la teora ele tromagneti a, no tena su iente forma ion matemati a para expli ar los
fenomenos ele tromagneti os de sus experimentos. La genialidad de Faraday lo ondujo a
rear sus propias abstra iones gra as, provenientes de sus observa iones experimentales,
a partir de las uales fundo y expli o el ele tromagnetismo. Al igual que Faraday, mu has
ve es reamos abstra iones que nos permiten omprender mejor un algoritmo. Estas
abstra iones onforman estru turas de datos. Un ejemplo muy notable es el on epto
de grafo. Etimologi amente, el termino grafo proviene de \gra o", pues los grafos son
expresados en terminos gra os. Sin embargo, en realidad, un grafo modeliza el on epto
de rela ion sobre el ual existe todo un orpus matemati o. A pesar del orpus y quiza
porque este es in ompleto, los grafos ofre en una vision gra a de la rela ion matemati a
on la que es mas omoda trabajar. Esta es otra razon que justi a el dise~no de una
estru tura de dato: una manera de representar el problema en terminos mas sen illos.
Estos tres tipos de orienta ion, de alguna forma lasi an el n o el \para que" se

1.4. Dise
no de datos y abstracciones

23

dise~na o se sele iona una estru tura de datos. La lasi a ion no es exa ta ni ex luyente.
Una estru tura de datos puede en ajar a la vez en diferentes momentos, bajo todos o
ualquiera de los tipos de orienta ion. Pero determinar en fun ion de las ir unstan ias
ual es la orienta ion de una estru tura de datos, puede guiar al programador en su dise~no
o sele ion.
1.4.2

El principio fin-a-fin

Consideremos el TAD hFigure 8ai y repitamos la pregunta fundamental: >para que sirve?,
> ual es su nalidad? En la se ion x 1.1.4 (pagina 8) se pretendio \generalizar opera iones inherentes al dibujado de una gura sobre algun fondo de ontraste". Con este n
denido, las opera iones del TAD hFigure 8ai, dibujar, mover, et etera, tienen sentido sin
ne esidad de ono er ual es la gura en uestion. Pensemos que su edera si no tuviesemos
laro para que se usara el TAD hFigure 8ai. La respuesta, no tan obvia en estos tiempos,
es que nos sera muy dif il omprenderlo. Si nuestro entendimiento no estuviese laro,
enton es, quiza, ometeramos el error de intentar implantar el TAD hFigure 8ai, el ual,
omo ya se men iono, es abstra to.
Ahora pensemos en ual sera la forma de un TAD Figure si este estuviese destinado a
al ulos geometri os en los uales, en lugar de dibujar, se al ulasen areas e interse iones
entre guras. Para este n, las opera iones del TAD hFigure 8ai no tendran mu ho
sentido.
Un prin ipio de dise~no de sistemas se ono e omo \el prin ipio n-a-n". Este onsiste
en no espe i ar, menos, dise~nar y mu ho menos implantar, mas alla del n que se onoz a
y se a uerde para el programa. Violar este prin ipio puede ostar esfuerzo vano, pues solo
en los puntos nales del programa, o en sus usuarios nales, se tiene todo el ono imiento
ne esario para dise~nar un programa on sentido [15.
En el ejemplo del TAD hComplejo 5i, tal omo lo hemos tratado, >que ono emos
a er a de su n? Los numeros omplejos tienen amplia apli a ion en ien ias y en ingeniera, razon por la ual un programador pudiera verse tentado a enrique er el TAD on
metodos o lases derivadas que fa iliten su futura manipula ion. Se podra, por ejemplo,
manejar oordenadas polares. Sin embargo, ampliar el TAD hComplejo 5i no tiene sentido si no se tiene la ertitud de que las oordenadas polares seran usadas por los usuarios
eventuales del TAD hComplejo 5i.
La observa ion anterior no se ha e para e onomizar trabajo -una ganan ia de onsuno
on el prin ipio n-a-n-, sino porque el interesado en un TAD hComplejo 5i extendido
on oordenadas polares podra manejar otra interpreta ion, en uyo aso, la extension
podra ser un estorbo.
Un TAD debe ser \mnimo" y \su iente". Por mnimo pretendemos indi ar que no
tiene mas de lo ne esario. Por su iente queremos de ir que debe ontener todo lo ne esario
para destinarlo al n para el ual fue denido. Estable er estas barreras es relativo, pues
depende del n y de su interpreta ion. De all, enton es, el ara ter esen ial que tiene,
para el exito de un proye to, el que el n este laramente denido y que los parti ipantes
no solo lo tengan laro, sino que esten omprometidos on el.
Quiza un aforismo de Saint-Exupery exprese mejor el sentido de minimalidad y su ien ia del prin ipio n-a-n: \Pare e que la perfe ion se al anza no uando no hay

24

Captulo 1. Abstracci
on de datos

mas nada que a~nadir, sino uando no hay mas nada que suprimir"10 .
1.4.3

Inducci
on y deducci
on

Indu ion signi a ir desde lo parti ular ha ia lo general, mientras que dedu ion se~nala
ir desde lo general ha ia lo parti ular. Cuando se dise~nan abstra iones, >por donde
omenzar?.
Es un prin ipio ono ido en edu a ion y dise~no el ir desde lo on reto ha ia lo abstra to.
En otras palabras, el forjar abstra iones a partir de la experien ia on reta real. En ese
sentido, uando no se tenga ono imiento ini ial a er a de un problema dado, el pro eso
de indaga ion debe omenzar a partir de fenomenos on retos del problema y, luego, a
partir de esas parti ularidades, intentar denir abstra iones.
En la programa ion a objetos existen dos me anismos de generaliza ion: la heren ia
de lases y las plantillas. La heren ia on ierne a los datos, mientras que las plantillas se
reeren al odigo.
La heren ia se apli a para delinear generalidades y omportamientos omunes a una
ierta lase de objeto. Las lases derivadas lasi an y aportan parti ularidades de omportamiento general y niveles de abstra ion. Cuando se identiquen lases o TAD, busque
que es lo omun y eso llevelo a lo general a traves de lases bases o abstra tas.
Hay dos aspe tos a generalizar mediante la heren ia de lases. El primero lo omponen
los atributos, o sea, las ara tersti as de un objeto dado. En el aso del TAD hFigure 8ai,
un atributo general lo onforma el punto de referen ia omun a todas las guras parti ulares. El segundo aspe to de generalidad es fun ional y ata~ne a las opera iones. En
el aso del TAD hFigure 8ai, los metodos virtuales draw(), move(), et etera, generalizan
opera iones omunes a todas las guras.
Como ya indi amos, algunos algoritmos son sus eptibles de ser generi os bajo la forma
de plantilla. Consideremos el problema de ordenar una se uen ia de elementos que sera
tratado en el aptulo 3. Notemos que el enun iado no men iona el tipo de elementos a
ordenar; solo espe i a que se trata de una se uen ia. Podemos ordenar apellidos, enteros
o elementos de ualquier otro tipo bajo el mismo esquema. Ordenar es independiente
del dato. En esta lase de problemas se puede dise~nar un ordenamiento generi o uyo
parametro sera el tipo de elementos.
Es importante desta ar que un omportamiento generi o apare e despues de ono er
omportamientos on retos y no al ontrario. Ni siquiera uando se posea una amplia
experien ia no se debe programar odigo generi o sin antes haberlo veri ado exhaustivamente on al menos un tipo de dato ono ido y on reto.
Para las dos te ni as de generaliza ion, heren ia y tipos parametrizados, el amino
omienza en lo on reto y se dirige ha ia lo abstra to, no al reves. Podemos de ir que este
es el estilo uando se dise~na y programa on sentido.
Conforme se gana experien ia on reta, un dise~nador puede onsiderar algunas generaliza iones a priori (no todas) sin aun ver las parti ularidades. Esto es dedu ion y es
posible despues de aprehender o dise~nar partes on retas de la solu ion.
La genialidad, uando o urre, es mirar en lo abstra to lo que puede devenir on reto.
Ingenio signi a tener genio desde adentro (in). Genio que genera ideas, buenas, por
10

Tradu ion del autor de: \Il semble que la perfe tion soit atteinte non quand il n'y a plus rien a
ajouter, mais quand il n'y a plus rien a retran her". Saint-Exupery. \Terre des hommes".

1.5. Notas y recomendaciones bibliogr

aficas

25

supuesto. Desde esta perspe tiva ingeniera es enton es la pra ti a del in-genio; pero no
se podra tener ingenio si siempre se exigiese permane er en lo on reto y se supeditase a
te ni as y metodos jos. Esta es la razon por la ual la intui ion nun a debe ser des artada.
1.4.4

Ocultamiento de informaci
on

Un TAD solo espe i a el n de un dato y su interfaz. Cuando se a uerda un dise~no en

torno a un TAD, se a uerda una espe i a ion objetiva que no di e nada a er a de su
implanta ion. Esto es ono ido omo el prin ipio de o ultamiento de informa ion, el ual
onsiste en o ultar deliberadamente la implanta ion de un TAD, pues, omo ya dijimos,
esta onforma lo subjetivo, el ual, no solo es mu ho mas omplejo, sino que di ulta la
omuni a ion.
A ve es es bueno hablar de la implanta ion on la interfaz. Por ejemplo, de ir que
hConjunto fundamental 19i esta implantado on arreglos ordenados propor iona una
idea a er a del desempe~no; se sabra, por ejemplo, que la busqueda es rapida, pero que
la inser ion y supresion son lentas. Notemos que en este aso no se dene exa tamente
omo se implanta el TAD, sino que se indi a, omo parte de la espe i a ion, un aspe to
general de la implanta ion.
Por tanto, la re omenda ion general de dise~no es que se o ulte lo mas que se pueda la
implanta ion. Pero si por razones de desempe~no o de requerimientos resulta onveniente
estable er un tipo de implanta ion, tratese esta enton es en los terminos mas generi os
posibles.

1.5

Notas y recomendaciones bibliogr

aficas

La programa ion orientada a objetos se remonta a nales de la de ada de 1960, uando
apare io el lenguaje Simula [2 on los on eptos de lase, heren ia y polimorsmo. Hay
dos observa iones histori as muy importantes. La primera es que Simula se ir uns ribio
en el dominio de la simula ion y no de la programa ion tradi ional. La segunda es que
todos los on eptos modernos de la orienta ion a objetos apare ieron primero que la no ion
matemati a de tipo de dato abstra to.
Simula no debe haberse tenido muy en uenta en su epo a porque trans urrieron
algunas de adas antes de que se le desempolvase y onsiderase en el paradigma a tual
de los objetos. Por el ontrario, los omputistas, que se reen muy elites os, ono en los
tipos abstra tos de datos desde los trabajos de Liskov y Zilles [10 y el o ultamiento de
informa ion desde los trabajos de Parnas [13.
El lenguaje C++ , veh ulo de ense~nanza del presente texto, inspirado en los lenguajes C [8 y Smalltalk [6, 1, 18, fue reado por Bjarne Stroustrup. La mejor referen ia para
su aprendizaje es su propio texto The C++ Programming Languaje [17, el ual, aparte
de que es posiblemente el mejor para omprender el lenguaje, es un ex elente tratado de
ingeniera de programa ion, que no tiene nada que ver on la geren ia de proye tos de
software, a tividad ahora injusta y vulgarmente ono ida bajo el rotulo de ingeniera del
software.
Este texto no versa sobre la interfaz de la bibliote a estandar C++ sino mas bien a er a
de su implanta ion. Es util sin embargo estudiar la interfaz a efe tos de no repetir trabajo

26

Captulo 1. Abstracci
on de datos

y de homogeneizar riterios. Una ex elente referen ia sobre la bibliote a estandar C++ es

el texto de Josuttis [7.
Un re uento histori o a er a del C++ y de la programa ion a objetos puede en ontrarse
en [16. La le tura es muy interesante porque revela que las abstra iones y on eptos
aso iadas a los objetos son resultado del renamiento a traves de errores y fra asos.
El prin ipio n-a-n ha sido observado desde epo as remotas, pero fue Guillermo de O am, uando enun io su elebre \navaja", la ual reza \no multiplique los entes sin
ne esidad", de quien primero se ono e su importan ia epistemologi a. En la programa ion, el prin ipio ha sido observado en grandes sistemas, siendo al respe to emblemati o
el art ulo de Saltzer et al [15. Sobre este art ulo es menester omentar que Saltzer et al
orientan su art ulo a sistemas distribuidos y no dire tamente al dise~no de datos. Por otra
parte, el termino \n" se interpreta a menudo omo \extremo" y no omo un proposito.
A traves de la experien ia se des ubren datos generales y generos de odigo. A una
ategora onsolidada de lase o odigo suele denominarsele \ omponente" o \patron". Un
repertorio bastante ri o de patrones generi os basi os puede en ontrarse en [4.
Si bien para dominar la programa ion se requieren algunos a~nos de experien ia omo
autor de programas, los textos de S ott Meyers [11, 12 onstituyen la mejor referen ia
para omprender, dominar y saber usar mu has de las idiosin rasias del C++ .
La historia de UML [5 se remonta a OMT [14, un lenguaje gra o, pre ursor del
a tual UML, propuesto por James Rumbaugh, un ient o elebre de la programa ion a
objetos. El onsor io OMG (Obje t Management Group), en el ambito de los sistemas
distribuidos a objetos, tomo OMT omo base para desarrollar el a tual UML.

1.6

Ejercicios

1. Dise~ne e implante un TAD que represente numeros en punto otante y en el ual se

espe ique la pre ision, es de ir, el tama~no de la mantisa y del exponente.
2. Critique el TAD hComplejo 5i. >Que tan ompleto es?, >es orre ta su espe i a ion
semanti a?, >Que problemas de dominio y resultados pueden o urrir?
3. Ample el TAD hComplejo 5i para manejar oordenadas polares. Dis uta donde
poner la amplia ion (en nuevos metodos, en una lase derivada, et etera)
4. Dise~ne e implante un TAD que represente numeros de pre ision arbitraria.
5. Revise fuentes de programas libres para dibujar omo Xfig y DIA e indague la jerarqua de lases on que ellos modelizan las guras.
6. Identique los objetos fundamentales para la ondu ion de un automovil que se
en uentran en la abina. Para ada uno, establez a su n y las opera iones junto
on sus espe i a iones sinta ti a y semanti a.
7. Dise~ne indu tivamente una jerarqua de lases que represente veh ulos automotores.
Dibuje los diagramas UML.
8. Dise~ne dedu tivamente una jerarqua de lases que represente \viviendas". Dibuje
los diagramas UML.

1.6. Ejercicios

27

9. Considere las siguientes lases de objeto uyos nombres sugieren lo que representan:
Medio areo

Medio de locomocin
Medio terrestre

Avin

Energa
Dirigible

Monopatn

Patineta

Patines

Moto

Bicicleta

Helicptero

Medio martimo

Globo

Barco

Submarino
Carreta

Cohete

Bus

Con motor

Tren
Sin motor

Dise~ne un esquema dedu tivo que rela ione estas lases.

10. Men ione tres o mas apli a iones en las que aparez a el problema fundamental de
las estru turas de datos. Para ada apli a ion, explique la forma en que apare e y
diserte brevemente a er a de omo se implantara.
11. Men ione tres o mas apli a iones en las que no aparez a el problema fundamental
de las estru turas de datos.
12. Men ione algunas estru turas de datos ono idas y dis uta su lasi a ion segun los
lineamientos expli ados en la se ion x 1.4.1 (pagina 22).
13. Dado un onjunto S denido por el tipo Set<T, Compare>, explique omo ono er
el elemento orrespondiente a la mediana en el sentido estadsti o.
14. Dado un onjunto S denido por el tipo Set<T, Compare>, explique omo se programara, en fun ion de las primitivas de hConjunto fundamental 19i, la rutina:
template <class __Set>
__Set extraer(__Set & set, int i, int j);

la ual extrae de S, y retorna en un nuevo onjunto, todos los elementos que estan
entre las posi iones i y j respe tivamente. Despues de la opera ion, S ontiene los
elementos entre los rangos [0..i 1] y [j + 1..n 1], donde n = |S|.
15. Asuma que el n de un sistema es la administra ion de la es olaridad de una arrera
universitaria. Bajo este n se desea disponer de bases de datos de estudiantes,
profesores, arreras, ursos, se iones, salones, horarios y demas aspe tos propios de
la administra ion es olar de una universidad.
Plantee TAD generales, parti ulares y parametrizados, que modeli en las diversas
abstra iones que manejara el sistema. Dibuje los diagramas UML para todas las
lases dise~nadas.
16. Re onsidere el ejer i io anterior para i los es olares de se undaria y primaria.

28

Captulo 1. Abstracci
on de datos

Bibliografa
[1 Byte, editor. Spe ial issue on Smalltalk, volume 6, August 1981.
[2 O. J. Dahl and K. Nygaard. SIMULA { an ALGOL-based simulation language. Communi ations of the ACM, 9(9):671{682, September 1966.

Interpretando Organiza iones... Una Teora Sistemi oInterpertativa de Organiza iones. Universidad de Los Andes - Consejo de pub-

[3 Ramses Fuenmayor.

li a iones - Consejo de Estudios de Postgrado, 2001.

[4 E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-Wesley,

1995.
[5 Obje t Management Group. OMG Unied Modeling Language 2.0 Proposal, Revised submission to OMG RFPs ad/00-09-01 and ad/00-09-02, Version 0.671.
OMG, http://www.omg. om/uml/, 2002.
[6 D. H. H. Ingalls. Design prin iples behind smalltalk. BYTE, 6(8):286{298, August
1981.
[7 Ni olai M. Josuttis. The C++ Standard Library: a tutorial and referen e. pubAW, pub-AW:adr, 1999.
[8 Brian W. Kernighan and Dennis Rit hie. The C Programming Language, Se ond
Edition. Prenti e-Hall, 1988.
[9 Donald E. Knuth. Fundamental Algorithms, volume 1 of The Art of Computer
Programming. Addison-Wesley, Reading, MA, USA, third edition, 1997.
[10 Liskov and Zilles. Programming with abstra t data types. Sigplan Noti es, 9, 1974.
[11 S ott Meyers. Ee tive C++. Addison Wesley, 1992.
[12 S ott Meyers. More Ee tive C++. Addison Wesley, 1996.
[13 D. L. Parnas. A te hnique for software module spe i ation with examples. Communi ations of the Asso iation of Computing Ma hinery, 15(5):330{336, May 1972.
[14 James E. Rumbaugh. OMT: The obje t model. JOOP, 7(8):21{27, 1995.
[15 J. Saltzer, D. Reed, and D. Clark. End-to-end arguments in system design. ACM
Transa tions on Computer Systems, 2(4), 1984.
[16 Bjarne Stroustrup. The Design and Evolution of C++. Addison Wesley, Reading
Mass., 1994.
[17 Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley, 3rd edition,
2000.
[18 Larry Tesler. The Smalltalk environment. Byte, 6(8):90{147, August 1981.