INDUCCION ESTRUCTURAL

P => Q
Probar que esto vale, no prueba que valga P ni que valga Q
(paratodo x) P(x)
Puedo olvidarme del cuantificador siempre que no suponga nada en particular sobre x
Cundo es correcto y cuando incorrecto mover o intercambiar cuantificadores?
EXPLICAR
qu es el principio de induccin?
para que sirve?
Cmo se usa?
Qu son HI y TI?
por qu funciona?
Para asegurarnos de cubrir todas las instancias nos aprovechamos del mismo mecanismo
que permite generar esas instancias
El esquema de la demostracin:
Uno o ms casos base y/o uno o ms pasos inductivos. Cada PI con su hiptesis inductiva
y su tesis inductiva.
Cuntos CB podramos necesitar? Cuntos PI? Depende nicamente de los generadores
Qu pinta tiene el universo de todos los trminos?
Qu pinta tiene el esquema de induccin estructural?
No se relacionan con la propiedad a demostrar, s con los generadores del TAD.
Generadores del TAD Esquema de demostracin Universo de instancias posibles.
(paratodo s: secu P(s)) => (paratodo s: secu, paratodo a:alfa) P(aS)
Ac la HI est afirmando lo que que queremos probar.
Cada paso inductivo ya es de por s una implicacin HI => TI
Plantear la propiedad como predicado unario. El predicado unario es lo que vamos a
demostrar que vale. Para plantearlo, tenemos que quitar el cuantificador que liga a la
variable sobre la que vamos a hacer induccin.
Ejemplo:
(paratodo s: secu) (long(duplicar(s)) = 2*long(s))
P(s) = [long(duplicar(s)) = 2*long(s)]
Luego (paratodo s:secu) P(s) es equivalente a lo que queremos demostrar.
El esquema de induccin consiste en los casos base y los pasos inductivos que vamos a
tener que probar. Este esquema es propio del tipo ya que se deriva de su conjunto de
generadores; los casos base se plantean sobre los generadores bsicos y los pasos
inductivos sobre los recursivos. Para cualquier propiedad que se quiera probar sobre un
TAD dado, el esquema de induccin es siempre el mismo:
(paratodo s: secu P(s)) => (paratodo a:alfa) P(aS)

P(s) es la HI y P(aS) es la TI
La idea es ir viendo qu axiomas podemos ir aplicando para ir reduciendo la expresin que
tenemos. Los axiomas nos brindan equivalencias por lo cual son reversibles.
Hay que tener cuidado de que todos los pasos de la deduccin hayan sido sii ya que
formalmente la deduccin logica es la que resulta de leer las expresiones desde abajo hacia
arriba.
En el paso inductivo asumimos que la HI es verdadera, ya que si es falsa, como el paso
inductivo es una implicacin con P(s) como antecedente, es trivialmente verdadero.
En el caso de los rboles por ejempo, reciben dos instancias de tipo ab(alfa) por lo tanto,
para el paso intuctivo la hiptesis inductiva ser:
(paratodo i,d: ab(alfa)) (P(i) yy P(d) => (paratodo a:alfa) P(bin(i,a,d))
Propiedades vlidas sobre el if:
- if p then q else q fi = q
-funcin (if p then q else r fi) = if p then funcin(q) else funcion(r) fi
- if !p then q else r = if p then r else q
- if p then (if p then q else r) else t = if p then q else t.
P=>Q es lo mismo que !P oo Q. Si P es false, la implicacin es trivialmente verdadera.
ESPECIFICANDO:
Los observadores deben permitirnos distinguir todas las instancias. Es decir, deberamos
poder definir todas las operaciones a partir de los observadores.
Los generadores deben permitirnos construir todas las instancias observacionalmente
distintas.
Una operacin f es congruente (respecto de la igualdad observacional) sii para cada par de
i =obsi tambin vale f(i) =obsf(i).
Cuando necesito poder determinar datos histricos incluir la operacin como otra
operacin podra no respetar la congruencia. Lo mismo si la incluyo como observador (ms
sutil). Una forma de resolverlo es agregando como observador bsico una funcin que
lleve la cuenta de la historia
TADs EN VARIOS NIVELES
Cuando definimos TADs que usan otros TADs internamente. Se hace principalmente para
agrupar informacin y simplificar TADs mediante el uso de otros y sus propiedades. Para
hacer que el TAD sea lo ms simple y consiso posible expresando todo lo que debe
expresar.
INTRODUCCION AL DISEO
En la etapa de especificacin nos ocupamos del qu?, lo explicamos usando TADs,
bajo el paradigma funcional.

En la etapa del diseo nos ocupamos del cmo?, lo explicamos con mdulos de
abstraccin usando el paradigma imperativo.
Un mdulo de abstraccin de divide en tres secciones:
Interfaz: seccin accesible para los usuarios del mdulo donde se detallan los servicios
exportados con la informacin relevante para el usuario, como efectos colaterales y
complejidad. (Parmetros formales, dependencias con otros modulos)
Representacin: Seccin no accesible a los usuarios del mdulo, donde se detalla y
justifica la eleccin de la estructura de representacin y los algoritmos con su complejidad.
Definicin de la forma en que se representan las instancias del tipo que estamos diseando,
eligiendo justificadamente una o ms estructuras.
Relaciones entre la representacin y la abstraccin que representa.
Son admisibles aquellas instancias de la estructura tales que Rep(e) es verdadero.
Abs est definido para cada instancia que hace verdadero el Rep y le asigna la instancia
correspondiente del TAD que estamos diseando.
Servicios usados: Donde se detallan todos los supuestos sobre los servicios que exportan
los otros mdulos.
Los servicios exportados de la interfaz de un mdulo deben satisfacer los requisitos
impuestos por las secciones de servicios usados de todos los mdulos que lo utilizan.
En la especificacin, las operaciones de los TADs se explican a travs de la axiomatizacin.
El comportamiento de las operaciones en la interfaz se explica mediante pre y pos
condiciones (estas se escriben usando las operaciones de los tads).
Punteros
& : tipo_dato -> puntero(tipo_dato)
* : puntero(tipo_dato) -> tipo_dato
NULL: puntero(tipo_dato)
REP y ABS
El rep indica si una instancia del tipo con el que represento para representar es o no vlida.
El Abs asigna la instancia correspondiente del tipo a representar a cada instancia del tipo
con el que represento.
Tener en cuenta para un buen rep:
- Coherencia en la informacin redundante: Hay que chequear que distintos campos que
proveen la misma informacin no se contradigan entre s.
- Restricciones del TAD: hay que chequear que se vean reflejadas en la estructura de
representacin.
- Decisiones de diseo: chequear las restricciones a la estructura de representacin que no
provengan de un chequeo de coherencia o de restricciones especificadas en el TAD.
Revisar no estar diciendo lo mismo varias veces.
Para un buen ABS:
- Recordar que tiene como restriccin al Rep

- Recordar que queremos identificar unvocamente la instancia del tipo representado y usar
una forma de asegurarlo
INTRODUCCION A ITERADORES
Tenemos contenedores/colecciones de cosas/tipos
El iterador se utiliza para recorrer los elementos de un contenedor, pueden ser pensados
como una abstraccin de los punteros.
Nos permite recorrer los elementos en algun orden.
Necesitamos alguna manera de crearlo, de acceder al elemento actual, de acceder al
prximo, de averiguar si hay ms.
Con eso alcanza para expresar de manera muy genrica:
Por cada elemento e de la coleccin C{
hacerAlgoCon(e);
}
Tambin existen iteradores: reversos, bidireccionales, con borrado (del elemento actual),
etc.
La idea es siempre la misma. Una abstraccin de por cada elem e de la coleccin A que
es independiente de la estructura de representacin interna de la coleccin A, e incluso
independiente de la interfaz que pudiera exportar cada tipo de coleccin A.
Si todos los contenedores exportan generadores de una manera estandar, entonces cualquier
contenedor se puede iterar del mismo modo.
Un iterador no debe confundirse con un mero puntero a un elemento. Conceptualmente,
podramos verlo como un puntero a un elemento en el contexto de una coleccin. Los
iteradores suelen tener estado.
Recordar por donde vamos podra ser ms complicado que un simple puntero.
Queremos poder tener mltiples iteradores de un mismo contenedor.
Si alguien modifica la coleccin que estamos iterando justo en medio de la recorrida No
est definido!
La estructura de representacin depende de cada caso.
ELECCION DE ESTRUCTURAS:
Tener muy en cuenta los invariantes:
- De nuestra estructura, para no olvidarnos de mantenerlos
- De estructuras conocidas, para poder aprovecharlas.
Tener punteros/iteradores/referencias cruzadas, puede servirnos para mejorar la
complejidad.
OJO! No podemos tener punteros a cosas de la estructura de representacin de otro mdulo
que no deberamos conocer. No romper el encapsulamiento!

Es conveniente tener en claro para qu sirve cada parte de nuestra estructura y estar
convencidos de que la estructura funciona antes de pensar los detalles ms finos.
ORDENAMIENTO
Cuando se tiene informacin extra sobre la entrada es posible conseguir algo de
complejidad menor a O(n log n)
APUNTE ESPECIFICACIN
Para resolver un problema es necesario tener una descripcin precisa del mismo, que pueda
interpretarse sin lugar a dudas. En este contexto nace la idea de utilizar un lenguaje formal
para especificar el comportamiento del software.
Los tipos abstractos de datos son modelos matemticos que se construyen con el fin de
exponer los aspectos relevantes del problema bajo anlisis (es un tipo de lenguaje formal
para especificar software).
Dado un objeto de estudio, la cantidad de detalles, situaciones e interacciones que se
pueden encontrar en l hacen imposible un anlisis exhaustivo del mismo que permita una
comprensin cabal sobre su funcionamiento.
Utilizar la abstraccin como herramienta para la comprensin es fundamental. Los TADs
buscan precisamente eso, y junto al concepto de encapsulamiento(ocultamiento de la
informacin), conforman una herramienta muy util para resaltar las cualidades relevantes
de lo que queremos analizar.
Los TADs son flexibles, generales, y no requieren de alta sofisticacin matematica para ser
usados.
Un TAD es el conjunto de modelos de una especificacin. Es decir, sus posibles
interpretaciones. Es lo que se entiende al leer una especificacin; es aquello que la
especificacin describe. Un modelo determina qu elementos del mundo real estarn
reflejados en la especificacin y que operaciones se permitir realizar sobre ellos.
Sintaxis(cmo se escribe?):
Para especificar un TAD es necesario definir:
1. la signatura: solo dice qu operaciones y con qu aridad deben tener los modelos
2. Los axiomas: que determinan el comportamiento de las operaciones. Son frmulas bien
formadas segn ciertas reglas (gramtica).
Los trminos son en nuestro caso las variables, los smbolos de constantes y los smbolos
de funcin aplicados a trminos.
Una frmula bien formada es cerrada si todas sus variables estn cuantificadas. Las
frmulas cerradas son las que son susceptibles de ser verdaderas o falsas.
Dada una especificacin de un TAD podemos utilizar reglas de inferencia para razonar
sobre la misma. Un sistema deductivo es un conjunto de axiomas y reglas de inferencias.

Al decir de primer orden queremos decir que incluye los axiomas de la lgica de primer
orden.
En nuestro caso los axiomas son los que damos explcitamente (ms los de la lgica de
priemr orden que estn implicitos) y las reglas de inferencia son:
-Modus Ponens: (p=>q,p) |- q, es decir si p implica q y vale p entonces vale q.
-Generalizacin: P(x) |- (paratodo x: P(x) si x no aparece en ninguna premisa. (a partir de
P(x) es posible concluir que para todo x P(x) )
- y las reglas de lgica ecuacional (reemplazo de iguales por iguales).
Los axiomas y aquellas cosas que se infieren a partir de ellos y las reglas de inferencia son
teoremas. Los teoremas son formulas bien formadas del sistema deductivo que tienen una
demostracin.
Ejemplo long(ab<>) > 0
Semntica(Qu significa):
Un ente matemtico es modelo de nuestra teora si hace corresponder a cda gnero del tad
un conjunto y a cada operacin una funcin (total).
Una teora es consistente cuando en ella no es cierto que verdadero es igual a falso. En las
teoras inconsistentes, todo es cierto y por ende no tienen modelos (con lo cual no modelan
en particular aquello que pretendamos modelar).
Cualquier modelo de un TAD representa a todas las instancias del TAD y las instancias son
infinitas.
Buscamos que un TAD modele cierto aspecto de la vida real (por eso tal vez todos los
videoclubes el planeta podan ser un modelo de tad, abstrayndonos de que estos son finitos
y mirando a cada videoclub como un ente matemtico)
Cuando implementamos, lo que queremos es que una clase asociada a una especificacin
de un TAD satisfaga que las implementaciones de las operaciones computen funciones con
las que puedo armar un modelo de la especificacin. lo que?
Metalenguaje
Hay una diferencia entre true constante del lenguaje y verdadero como el resultado que se
obtiene de evaluar una frmula cerrada. (verdadero y falso perteneces al metalenguaje y no
forman parte de los TADs)
Especificar:
Se trata de capturar lo ms fielmente posible y con precisin matemtica, un problema para
el que luego encontraremos una solucin. En esta etapa lo que debe preocuparnos es el
problema a resolver y no sus soluciones.
Al realizar la especificacin de un problema en realidad estamos trabajando sobre una
abstraccin del mismo. Es decir, lo ms probable es que lo que reflejemos en nuestro
modelo sean los aspectos importantes de aquel ente que queremos capturar. La abstraccin
se trata de dejar de lado los detalles que no son importantes a los fines que perseguimos,
para concentrarnos en aquellos aspectos que son fundamentales.

A la hora de escribir los axiomas para nuestras operaciones debemos tener en cuenta que
siempre son funciones totales (esn definidos para todo valor de su dominio).
En este sentido al utilizar restricciones estamos subespecificando, en el sentido de que
estamos dejando constancia que no vamos a decir qu valores toma la funcin cuando sus
parmetros no cumplen con la restriccin.
Sin embargo debemos ser cuidados de dotar al resto de los valores del dominio de su
correspondiente imagen. Si determinado valor de los parmetros de una operacin es vlido
de acuerdo a las restricciones, entonces deberamos indicar, mediante los axiomas, cual es
el resultado de la funcin para esos valores (o qu caractersticas tiene, como por ejemplo
con el dameUno).
Tampoco se debe sobreespecificar. Cuando hay varias formas de saber el resultado para
unos valores dados de sus parmetros. El problema se presenta cuando dependiendo de
nuestra eleccion obtenemos valores distintos (recordemos que son funciones). Podemos
obtener inconsistencias y privar a nuestra teora de modelos.
La idea de dejar algunos aspectos particulares sin una definicin precisa es un recurso muy
til para manejar algunas incertidumbres a la hora de especificar. Si no lo hacemos, a veces,
cualquier implementacin que utilice otro criterio no satisface nuestra especificacin. A
veces una caracterizacin ms debil nos permite decidir al implementar.
Igualdad observacional.
Para los TADs una semntica posible es la semntica inicial, que burdamente descripta
trata de partir el universo de acuerdo a las ecuaciones que aparecen en el TAD. Al hacer
esto, se obtiene que todos los trminos se interpretan en el modelo como distintos, excepto
que haya ecuaciones que permitan deducir que son iguales.
Ventaja: la relacin de igualdad que queda definida en el modelo es una congruencia (esto
es, cosas que estn en la misma clase de equivalencia van a la misma clase de equivalencia
sin importar qu funcin se les aplique). Desventaja: los modelos no son muy bonitos salvo
que uno agregue axiomas ad hoc (para este propsito).
Debido a este problema se invent a semntica observacional. Algunas funciones se
etiquetan como observadores bsicos. El universo se particiona de acuerdo a ellos.
Ventaja: los modelos son ms bonitos, legibles e intuitivos. Deventaja: en el caso general, la
igualdad del modelo no es una congruencia (la igualdad de trminos no se interpreta con
una congruencia)
Observadores bsicos
Son un conjunto de funciones pertenecientes al TAd que permiten particionar el universo de
sus instancias en clases de equivalencia, con la idea de agrupar en cada clase a las
instancias que posean un comportamiento similar con respecto al estudio que queremos
realizar. En particular, deseamos que el TAD se convierta en una congruencia, es decir, una
relacin de equivalencia en la que si se aplica cualquier operacin a dos instancias de la
misma clase, los resultados obtenidos tambin formen parte de la misma clase
(correspondiente al TAD al que pertenzca el resultado).
Es importante a la hora de elegir los observadores, tener en claro cuando vamos a
considerar que dos instancias son iguales. Si comparamos dos instancias
observacionalmente iguales no debera pasar que al aplicar un observador a ambas

obtengamos resultados distintos, porque en ese caso el TAD no se comportara como una
congruencia (sus funciones no lo haran).
No deberan existir observadores que solo identifiquen aspectos de la instancia que ya han
sido identificados por los otros observadores.
Generadores
Son un conjunto de funciones que retornan un resultado del gnero principal del TAD
especificado, y que tienen la particularidad de que a partir de una aplicacin finita de ellos
se pueden construir o generar absolutamente todas las instancias del TAD.
No puede existir una instancia de un TAD que no se pueda generar a partir de una sucesin
de aplicaciones de sus generadores.
Definir generadores de ms, dificulta la axiomatizacin de las funciones y lleva a la posible
aparicin de errores e inconsistencias en la especificacin.
Generadores bsicos o no recursivos: los que reciben como parmetro ninguna instancia
del tipo que estn generando.
Generadores recursivos: los que reciben como parmetro al menos una instancia del tipo
que estn generando.
Este punto es fundamental a la hora de realizar demostraciones de propiedades sobre tipos
abstractos de datos, ya que nos ofrece un esquema de demostracin dividido en dos partes.
La primer parte demuestra la propiedad para todas las instancias generadas por generadores
base, y la segunda demuestra la propiedad para todas las instancias generadas por
generadores recursivos, suponiendo que la propiedad es vlida para las instancias del TAD
que reciben como parmetros (que a su vez estn generadas a partir de los generadores base
o recursivos).
Al aplicar un generador recursivo a una instancia de un TAD no se est modificando la
instancia que recibe como parmetro ya que en nuestro lenguaje abstracto no existe la
nocin de cambio de estado, sino que se est generando una nueva instancia basada en la
anterior.
Otras operaciones
No debera ocurrir que una funcin que aparezca en esta seccin devuelva valores distintos
cuando se aplique sobre dos instancias observacionalmente iguales del TAD.
Restricciones
Son una parte fundamental de un TAD, con ellas explicitamos los casos para los cuales
ciertas operaciones no tienen sentido, aportan claridad y coherencia a una especificacin.
Aportan expresividad a nuestro lenguaje ya que nos permiten limitar el universo al cual
aplican ciertas operaciones de nuestros TADs
Gneros
Es el nombre colectivo con el que se va a hacer referencia a instancias del TAD que
estamos definiendo.
Recursin:

Una definicin es recursiva si hace referencia a s misma. Define una cosa en funcin de las
interpretaciones ms simples de la misma.
La idea es que al ir simplificando se llega a un punto donde no se puede simplificar ms, el
caso base. All la definicin se resuelve directamente sin usar el concepto que se esta
definiendo. Para resolver el caso base, nos basta con saber qu tiene que devolver la
funcin para ese caso particular.
Debemos garantizar que eventualmente se llegar al caso base para todos los valores
sobre los cuales se encuentra definida la operacin. La manera ms habitual de garantizar
esto es que en cada caso recursivo se logre disminuir la complejidad de los parmetros
invlucrados.
No axiomatizar sobre casos restringidos ni sobre generadores de otros tipos.
Sobre lo segundo, a veces tenemos una operacin auxiliar que recibe elementos de tipos
definidos en otros TADs. Al realizar estas axiomatizaciones lo preferible es que ellas se
efectuen en funcin de los observadores bsicos del tipo usado y no sobre los generadores
(nuestra operacin podra violar la igualdad observacional del tipo usado).
Parmetros formales:
Podra entenderse como una variable del tipo. alfa TAD Conj(alfa), TAD Secu(alfa) (alfa
es el parmetro formal).
DISEO JERARQUICO DE TIPOS ABSTRACTOS DE DATOS
Al disear comenzamos a resolver el problema. Centraremos nuestro interes en el tipo
(TAD) como en los aspectos que se necesitan para optimizarlo (espacio, tiempo de
ejecucin).

Un tipo se define por sus funciones antes que por sus valores. La forma en que los valores
se representan es menos importante que las funciones que se proveen para manipularlos.
Los generadores de los tipos describen la forma abstracta de construir elementos, nunca la
forma de construirlos o representarlos fsicamente.
Con el propsito de implementar un tipo deberemos:
- proveer una representacin para sus valores,
- definir las funciones del tipo en funcin de las de su representacin
- demostrar que las funciones implementadas satisfacen las relaciones especificadas en los
axiomas.
Nuestra metodologa del diseo parte de un modelo abstracto (nuestra especificacin) no
implementable directamente en un lenguaje imperativo de programacin y aplicar
iterativamente sobre dicho modelo sucesivos pasos de refinamiento (desabstracciones)
hasta llegar a estructuras que s son implementables.
Cada iteracin de este proceso definir un nivel de nuestro diseo. Por su parte, cada uno de
estos niveles tendr asociado uno o ms modulos de abstraccin que bsicamente indicar
como se resuelven las operaciones de un mdulo utilizando otras de mdulos del nivel
inmediato inferior.
Los modulos de abstraccin son implementables en un lenguaje de programacin.

Los mdulos de un cierto nivel son usuarios de los servicios que les brindan los de nivel
inmediato inferior, y no conocen (ni usan) a los mdulos de otros niveles).
Para utilizar un tipo, no se accede directamente a la estructura que lo representa sino que se
accede a travs de la interfaz que se le define.
Cualquier cambio de implementacin del nivel n ser transparente al nivel superior n+1
siempre que el nivel n mantenga su interfaz. El mdulo exporta al menos las mismas
funciones que se exportaban antes, y la funcionalidad provista por las mismas no cambi,
aunque puede haber mejorado su performance.
Paradigma imperativo.
En el paradigma funcional los datos solo tienen sentido en cuanto sean argumentos o
resultados de funciones, sin embargo, en el paradigma imperativo, los datos son tratados
como entidades independientes de las funciones que los utilizan. Es usual que se trabaje
con una instancia de un objeto que se va modificando y cuyos valores anteriores no
interesen. Por lo tanto, por cuestiones de optimizacin y su uso, no tiene sentido construir
cada vez un objeto nuevo para devolverlo como resultado de una funcin.
El mapeo de los parmetros de las funciones del tipo en las operaciones del mdulo no
siempre es uno a uno. Por ejemplo, puede ser que la interfaz haya agregado requerimientos
en el contexto de usoetc
Pasaje de parmetros:
Se deber tener en cuenta que los parmetros de tipos primitivos (bool , nat, int, real, char,
puntero) y solo estos siempre se pasan por valor y los de tipos no primitivos siempre se
pasan por referencia.
Si fuera necesario construir una copia de un parmetro de tipo no primitivo, dicha copia
debe ser explcita. Todo mdulo que se disee y cuyas instancias se desee copiar, deber
proveer una funcin a tal efecto.
Mtodo:
El orden en el cual se disean los tipos es arbitrario. Sin embargo, es una buena prctica
comenzar por los tipos mas importantes pues estos sern los principales generadores de
requerimientos de eficiencia para los tipos menos importantes (modalidad top-down).
Al disear un mdulo, no necesariamente debemos disear todos los tipos que usamos en la
especificacin.
Por ejemplo si en la especificacin tenemos al cardinal de un conjunto como:
Cardinal(c) = long(VolcarElementosEnSecuencia(c))
Deberamos plantear si tiene sentido considerar en el diseo al tipo secuencia. Si realmente
nos interesa ofrecer una funcin que vuelque el conjunto en una secuencia, habr que
disear eventualmente el tipo secuencia. Pero si no se exporta y no aparece visible en
ningn otro lado de la especificacin, en principio no sera necesario y la funcin cardinal
podra implementarse de otra manera sin pasar por la secuencia.

No es importante la manera en que se axiomatizaron las funciones si no lo que esos

axiomas significan.
Cada mdulo de abstraccin est compuesto por dos secciones, la definicin de la interfaz y
la definicin de la representacin. En la interfaz se describe bsicamente la funcionalidad
del mdulo y en qu contexto puede ser usada. En la representacin se elige, bajo algn
criterio, una forma de representacin utilizando otros mdulos y se resuelven las
operaciones del mdulo en funcin de su representacin.
En este punto, un diseo puede contener tipos para los que no tenemos una propuesta de
diseo. Son otros problemas a resolver de un nivel de abstraccin menor al original.
Para escribir las precondiciones y las poscondiciones usaremos un lenguaje de descripcin
de estados aprovechando la especificacin del tipo a disear.
Tambin es importante, en las operaciones que quitan elementos de la estructura indicar si
estos elementos seguirn existiendo o sern eliminados. Esto afecta a los usuarios que
tengan referencias a dichos elementos. Si se los elimina, las referencias a ellos dejarn de
ser vlidas. En caso contrario, seguirn vigentes pero ya no estarn en la estructura, por lo
que ser el usuario el encargado de liberarlas al momento de implementar su mdulo.
No se puede saber si un diseo es adecuado, si no se aclara precisamente el contexto de
uso. La idea es que la principal justificacin para el resultado obtenido en cada iteracin de
diseo es el contexto de uso que se le impuso al diseador.
Eleccin de la estructura.
Hay que tener en cuenta cuales son las operaciones que nos interesan optimizar y en qu
contexto de uso sern utilizadas. Adems es muy importante considerar criterios de
optimizacin tales como: espacio de disco, espacio de memoria, tiempo de ejecucin,
reusabilidad, claridad y sencillez de la implementacin, homogeneidad de los algoritmos,
etc.
Las variables en un programa referencian valores. Ser imposible el acceso a la
implementacin interne de estos, y esto redundar en la modularidad de nuestro diseo y en
el ocultamiento de informacin. Este nos permite hacer invisibles algunos aspectos que
sern encapsulados. Esto es til para aumentar el nivel de abstraccin y disear cdigo que
sea ms fcilmente modificables, mantenible y extensible. Al acceder a los objetos solo a
travs de su interfaz, no nos atamos a su implementacin, solo a su funcionalidad.
Cualquier cambio de implementacin en un tipo que no altere la funcionalidad no nos
obligar a redisear los tipos superiores.
Relacin entre la representacin y la abstraccin
Invariante de representacin
Es un predicado que nos indica si una instancia del tipo de representacin es valida para
representar una instancia del tipo representado.
Es el conocimiento sobre la estructura que necesitan las distintas operaciones para
funcionar correctamente y que garantizan finalizar. Quedan expresados en el las
restricciones de coherencia de la estructura, surgidas de la redundancia de informacin que
pueda haber.

Su dominio es la imagen funcional del tipo que estamos implementando. Esto es necesario
para que podamos tratar los elementos del dominio en lgica de primero orden. Su
imagen no es el genero bool si no los valores lgicos verdadero o falso.
Rep toma la imagen abstracta (funcional, del mundo de los TADs) de la representacin
del tipo.
Puede que en algun caso todas las instancias del tipo de representacin sean vlidas (Rep =
TRUE)
Funcin de abstraccin:
Tiene por dominio al conjunto de instancias que son la imagen abstracta del tipo de
representacin y que verifican el invariante de representacin, y devuelve una imagen
abstracta de la instancia del tipo representado (aquella instancia que estamos pretendiendo
representar).
La funcin de abstraccin debe ser sobreyectiva, al menos con respecto al universo que nos
ha restringido nuestro contexto de uso. Si no lo fuera, significara que hay elementos del
tipo que queremos representar que no podrn ser efectivamente representados. Por ejemplo,
con un arreglo [1..20] de nat no podemos representar conjuntos de ms de 20 elementos. La
estructura sera vlida si el contexto de uso nos garantiza que efectivamente no
manejaremos tales conjuntos.
No necesariamente debe ser inyectiva (ver ejemplo anterior)
Todo debe devolver algo del universo que representamos pero quizas haya cosas del
universo que no puedan ser hechas con esta estructura?
Tenemos dos maneras de escribir la funcin de abstraccin. La primera, en funcin de los
observadores bsicos. Dado que estos identifican de manera unvoca al objeto del cual
hablan, al hablar del valor que tienen los observadores bsicos aplicados al objeto, estamos
describiendo sin ambigedad el objeto representado.
Otra forma de describir la funcin de abstraccin es en funcin de los generadores del tipo
de representacin. Por ejemplo, en un conjunto implementado sobre una secuencia:
Abs(<>) = (conj vaco)
Abs(nS) = Ag(n, Abs(s)).
Algoritmos
En este paso se implementan las operaciones del tipo a disear en trminos de operaciones
de los tipos soporte. Deben aparecer algoritmos de cada una de las operaciones, de la
interfaz o auxiliares. En el caso de las funciones auxiliares, es bueno incluir, junto con sus
algoritmos, sus precondiciones y poscondiciones.
Al escribir los algoritmos, agregamos una i al nombre de la funcin, para interpretar que el
parmetro que recibe es del tipo de representacin y por ende se puede acceder a su
estructura. Por ejemplo, tenemos un conjunto representado con una secuencia. La interfaz
tendr Agregar(in/out c: conj(nat), in n:nat). Un tipo que lo ve desde afuera debe invocar a
la interfaz, y asumimos que el lenguaje de implementacin se encarga de la conversin de
tipos.

Al hacer la funcin, no nos metemos dentro de la estructura de representacin de la

secuencia, por lo que no hacemos asunciones acerca de cmo est implementada. De esta
manera, un cambio en la implementacin de secuencia no tendra impacto en el diseo de
nuestro conjunto.
Cuando una operacin pertenece a otro mdulo, el cdigo est oculto a los dems mdulos.
Lo nico que se necesita para usarlo es conocer las operaciones exportadas.
Servicios usados:
Aqu es donde indicamos que responsabilidades le dejamos a los tipos soporte que usamos.
Son las pautas de requerimientos que se extraen del diseo de este tipo para el diseo de los
tipos de la representacin. Luego pasarn a ser las interfaces y los contextos de uso y
requerimientos de eficiencia para los mdulos soporte de los tipos usados.
APUNTE ITERADORES:
La necesidad de los iteradores surge con la implementacin de un algoritmo que utilice
alguna estructura contenedora, puesto que es de esperarse que en algn momento sea
necesario recorrer los elementos que esta contiene.
Por ejemplo, en la secuencia o el conjunto, la unica forma para iterar los elementos es
destruirlos (dameUno, fin), por lo que sera necesario hacer una copia para no destruir el
original. Esto hace notar un problema puesto que no es posible utilizar el contenedor sin
copiarlo.
Iteradores
Un iterador, en su forma ms simple, es una estructura de datos que permite recorrer de
forma eficiente otra estructura. No tenerlos trae dos tipos de problemas:
- Copiado innecesario: Dado que la nica forma de iterar una estructura es a traves de
operaciones que la destruyen, es necesario realizar una copia previa a iterarla.
- Especificidad de los algoritmos: Dado que el mecanismo de iteracin es el diferente para
cada estructura, es necesario implementar algoritmos bsicos para cada una.
Dado que se pretende que la implementacin de un iterador no realice una copia del
contenedor que va a iterar, es de esperarse que conozca su estructura interna. Es por esto
que para cada contenedor, habr que disear su iterador.

GLOSARIO
En el anlisis matemtico, la aridad de un operador matemtico o de una funcin es el nmero
de argumentos necesarios para que dicho operador o funcin se pueda calcular.
En matemtica, una funcin
es sobreyectiva (epiyectiva, suprayectiva, suryectiva, exhaustiva o subyectiva), si est aplicada sobre todo
el codominio, es decir, cuando cada elemento de "Y" es la imagen de como mnimo un elemento de "X".
En matemticas, una funcin

es inyectiva si a elementos distintos del conjunto

(dominio) les

corresponden elementos distintos en el conjunto

(imagen) de . Es decir, cada elemento del conjunto Y tiene a lo
sumo una antiimagen en X, o, lo que es lo mismo, en el conjunto X no puede haber dos o ms elementos que tengan
la misma imagen.
En matemticas, una funcin es biyectiva si es al mismo tiempo inyectiva y sobreyectiva; es decir, si todos los
elementos del conjunto de salida tienen una imagen distinta en el conjunto de llegada, y a cada elemento del
conjunto de llegada le corresponde un elemento del conjunto de salida.