modelo persistente

19
ESTRUCTURA DE DATOS II ESTRUCTURA DE DATOS II MEMORIA PERSISTENTE MEMORIA PERSISTENTE EXPOSITOR: EXPOSITOR: Ing. Evans Balcazar Veizaga Ing. Evans Balcazar Veizaga

Upload: guest0fc4fa

Post on 21-Jul-2015

7.780 views

Category:

Travel


3 download

TRANSCRIPT

ESTRUCTURA DE DATOS IIESTRUCTURA DE DATOS IIMEMORIA PERSISTENTEMEMORIA PERSISTENTE

EXPOSITOR:EXPOSITOR:

Ing. Evans Balcazar VeizagaIng. Evans Balcazar Veizaga

DEFINICION

VENTAJAS DEL MODELO PERSISTENTE

DESVENTAJAS DEL MODELO PERSISTENTE

EJEMPLO

BIBLIOGRAFIA

A la característica que le permite a un objeto existir mas allá del tiempo de vida del programa que lo instancia, se le llama persistencia, de tal suerte, los objetos pueden se clasificados como :

Transitorios: Cuyo tiempo de vida depende directamente del

ámbito de la función que los instanció (o del programa en caso de ser globales).

Persistentes:Cuyo estado es almacenado en un medio secundario para su posterior reconstrucción y

utilización, por lo que su tiempo de vida es independiente del programa que los

instanció.

Existen varias formas en las que un programador puede resolver el problema del almacenamiento de objetos Una de ellas es escribir directamente los objetos en archivos, para lo cual el programador deberá crear el código que a partir de las librerías del lenguaje le permitan almacenar y recuperar los objetos.

En esta modalidad, el programador deberá convertir las representaciones en memoria de los objetos a flujos de bytes (a este proceso se le conoce como serialización).

La serialización y todas las demás consideraciones de almacenamiento (manejo de archivos, indexación, distribución, paginación, relaciones entre objetos, etc...) quedan a cargo del programador. Esto requiere de un gran esfuerzo de programación.

Actualmente, coexistiendo con estos sistemas anteriormente mencionados están surgiendo nuevas iniciativas, la mayoría de ellas ideadas para conseguir que los lenguajes de programación soporten objetos persistentes.

Persistencia en JavaSi nos centramos en el lenguaje de programación Java, por ejemplo, vemos que existe un amplio abanico de posibilidades cara a conseguir dicho objetivo. Así, nos encontramos con proyectos como Pjava (Persistent Java), que proporciona un entorno de programación persistente para el lenguaje Java basado en una modificación de su plataforma.

Esquema general para la inclusión de funcionalidades de bases de datos en un lenguajede programación.

Persistencia en C++

El operador new (palabra clave C++) proporciona espacio de almacenamiento persistente, similar pero superior a la función de Librería Estándar malloc. Este operador permite crear un objeto de cualquier tipo, incluyendo tipos definidos por el usuario, y devuelve un puntero (del tipo adecuado) al objeto creado.Su utilización exige que el usuario declarare un puntero del tipo adecuado; a continuación debe ser inicializado con el valor devuelto por el operador. Si el objeto creado es tipo T, sería algo así:

T* puntero = valor-devuelto-por-el-operador;

Los objetos creados con new son persistentes, es decir, la vida del nuevo objeto es desde el punto de creación hasta el final del programa o hasta que el programador lo destruya explícitamente con el operador delete. Este último desasigna la zona de memoria ocupada por el objeto, de forma que queda disponible para nuevo uso. Las sucesivas invocaciones de este operador van reservando zonas de memoria en el montón para los objetos sucesivamente creados. El gestor de memoria del compilador se encarga de mantener una tabla con los sitios ocupados y libres sin que haya conflictos hasta que la memoria se ha agota, o no existe espacio contiguo suficiente para el nuevo objeto. En cuyo caso se lanza una excepción como indicativo del error.

PeligrosLa persistencia de los objetos creados con new y su independencia del ámbito desde el que han sido creados, es muy importante y de tener en cuenta, pues suele ser motivo de pérdidas de memoria en el programa si olvidamos destruirlos cuando ya no son necesarios . Hay que prestar especial atención, porque en una sentencia como:voidfunc() { ... tipoX* Xptr = new tipoX; ...}

el área de almacenamiento señalada por el puntero es persistente, pero Xptr que es una variable local automática no lo es. Si olvidamos destruir el objeto creado (con delete) antes de salir del ámbito, el área de almacenamiento permanecerá ocupando espacio en el montón y no podrá ser recuperada nunca, pues el puntero Xptr habrá desaparecido.La cuestión de pérdida de memoria no es solo cuestión de que el programador "recuerde" utilizar delete antes de salir del ámbito del puntero. También puede producirse por otras circunstancias. Por ejemplo, el mecanismo de lanzamiento y captura de excepciones C++ puede funcionar como un salto, goto o break multinivel, que saque abruptamente de ámbito al puntero con la consiguiente pérdida irreparable. La situación puede ser esquematiza como sigue (la figura adjunta muestra el estado de la pila y el alcance del desmontaje -"Stack unwinding"- caso de producirse un error).

fun1() { try { fun2(); } catch (...) { ... }}fun2() { A* aptr = new A; // crear objeto foo(); ... delete aptr; // Ok. destruir el objeto} // antes de salir de ámbito foo() { ... if (x) throw "Error"; ...}

La situación anterior es de gran peligro potencial. Si se produce la condición x, y se lanza la excepción en foo, la pila será desmontada hasta el punto de la sentencia catch en fun1 que recibirá el control. La secuencia de ejecución no pasará nunca por el delete de fun2, con lo que el espacio del objeto A se perderá irremediablemente.Conscientes del deficiente maridaje entre el operador new y el sistema C++ de excepciones, los diseñadores de la Librería Estándar, han incluido en esta un puntero "inteligente" auto_ptr, que resuelve este tipo de problemas.

La persistencia permite al programador el almacenar, transferir y recuperar el estado de los objetos.

La persistencia es muy difícil de implementar puesto que es muy compleja ya que le exige al programador el manejo de Puntero.

Todo objeto creado de forma persistente debe de ser destruido cuando ya no se lo necesita puesto que ocasiona pérdidas de memoria en el programa si olvidamos destruirlos.

#include<conio.h>#include<iostream.h>#include <vcl.h>#pragma hdrstop#include <fstream.h>class persona{ private: String nombre; public: persona(); void setnom(String s); String getnom();};persona::persona(){ nombre="vacio";}void persona:: setnom(String s){ nombre=s;}

String persona::getnom(){ return nombre;}

void main (){ persona p,q; p.setnom("iris"); ofstream out; out.open("persona.dat"); out.write((char*)&p,sizeof(persona)); out.close(); ifstream in; in.open("persona.dat"); in.read ((char*)&q,sizeof(persona)); out.close(); cout<< q.getnom(); getch();}

[4] M. Atkinson, L. Daynès, M. Jordan, T. Printezis, S. Spence. An Orthogonally Persistent Java. SIGMOD Record, Vol 25 Nº4. December,1996[5] Steven T. Abell. Using Java with PSE. Java White Paper. http://www.odi.com, March 1999.

http://www.programación.comAutora y Enviado por: ROCIO BAILON CARPIO con correo [email protected] el día 10 de julio de 2006PROGRAMA DE VISUAL BASIC 5.0A:http://www.Programación en castellano_ Foros de debate_ Visual FoxPro programacion gratis.htmCopyright © 1999-2006 Programación en castellano. Todos los derechos reservados. Información extraide de dicha página web a las 9:30 pm. El día viernes 15 de septiembre de 2006.

http://www.itlp.edu.mx/publica/revistas/revistali/anteriores/marzo99/actual3.htmlhttp://www. Formas de Proveer la Persistencia.htm Autor: Ing. Marco Antonio Castro Liera. Información extraide de dicha página web a las 8:00 pm. El día Jueves 14 de septiembre de 2006.

Ambler, S. “Persistence layer requirement”. Software develpoment. 6(1) 70-71, January 1998.

Ambler, S. “Persistence modeling in the UML”. Software Development Magazine. http://www.sdma gazine.com/articles/1999/ 0008a.htm. August 1999.

Ambler, S. “The Design of Robust Persistence Layer for Relational Database”. http://www.amysoft.com/ persistencelayer.pdf. October 21, 2000.

Sitio Web http://www.zator.com/CPP/E4_9_20a.html Autor Copyright © 2000-2006 Zator Systems. Información extraída de dicha pagina el 26 de septiembre de 2006 a las 9:25 pm.