pract e ped 2012

7/30/2019 Pract e Ped 2012

1/23

Estrategias de Programacion

y Estructuras de Datos

Enunciado de la Practica

Curso 2.011-12

Enunciado de la Practica EPED curso 2.011-12-1 -

7/30/2019 Pract e Ped 2012

2/23

Indice

1. Introduccion 4

2. Descripcion del Problema 5

2.1. Organizacion fsica del disco en clusters . . . . . . . . . . . . . . . . 5

2.2. La Tabla de Asignacion de Ficheros . . . . . . . . . . . . . . . . . . 5

2.3. Directorios y Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4. Comandos del Sistema de Ficheros . . . . . . . . . . . . . . . . . . . 8

3. Desarrollo de la practica 10

3.1. Codigo cerrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Paquete es. uned.lsi .eped.filesystem .disk . . . . . . . . . . . 13

3.1.2. Paquete es. uned.lsi .eped.filesystem .os . . . . . . . . . . . . 13

3.1.3. Paquete es. uned.lsi .eped.filesystem . fs . . . . . . . . . . . . 14

3.1.4. Paquete es.uned. lsi .eped.filesystem .cmd . . . . . . . . . . . 14

3.1.5. Paquete es. uned.lsi .eped.filesystem . . . . . . . . . . . . . . 15

3.2. Codigo abierto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1. Paquete eped.filesystem .os . . . . . . . . . . . . . . . . . . . 15

3.2.2. Paquete eped.filesystem . fs . . . . . . . . . . . . . . . . . . . 153.2.3. Paquete eped.filesystem .cmd . . . . . . . . . . . . . . . . . . 16

4. Plan de trabajo 17

4.1. Actividad 0. Instalacion y preparacion del entorno . . . . . . . . . . 17

4.2. Actividad 1. Desarrollo de la FAT . . . . . . . . . . . . . . . . . . . 18

4.3. Actividad 2. Desarrollo de la DirTable . . . . . . . . . . . . . . . . . 18

4.4. Actividad 3. Desarrollo del FileManager . . . . . . . . . . . . . . . . 18

4.5. Actividad 4. Desarrollo del DirectoryManager . . . . . . . . . . . . . 18

4.6. Actividad 5. Implementacion de comandos . . . . . . . . . . . . . . . 18

5. Evaluacion y calendario de entrega 20

5.1. Fases de la realizacion de la practica . . . . . . . . . . . . . . . . . . 20

5.2. Fechas de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3. Evaluacion y calificacion . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.4. Criterios de calificacion . . . . . . . . . . . . . . . . . . . . . . . . . 21

6. Referencias 23

7/30/2019 Pract e Ped 2012

3/23

INDICE DE FIGURAS INDICE DE FIGURAS

Indice de figuras

1. Estructura de un disco duro ( c WikiMedia Commons) . . . . . . . . . . 52. Disposicion de ficheros en disco duro (FAT) . . . . . . . . . . . . . . 6

3. Contenido del proyecto de desarrollo de la practica . . . . . . . . . . 10

4. Diagrama de clases de diseno de la practica . . . . . . . . . . . . . . 12

5. Modelo de comentario que describe una tarea . . . . . . . . . . . . . 17


7/30/2019 Pract e Ped 2012

4/23

1 INTRODUCCION

1. Introduccion

La practica de la asignatura Estrategias de Programacion y Estructuras de Datos-correspondiente al curso academico 2.011-2.012 que presentamos en este documentopretende poner en contacto a los alumnos con un problema practico donde los con-tenidos de la asignatura -tipos abstractos de datos, diseno de algoritmos y analisisde la complejidad- se muestran como herramientas de util aplicacion recurrentepara resolver problemas complejos como el aqu descrito. El objetivo general eneste sentido es doble. Por un lado se pretende motivar al estudiante en el estudiopractico de la asignatura, mientras que por otro lado se proporciona un contextode experimentacion donde los alumnos puedan poner en practica los conocimientosadquiridos de forma progresiva, razonada y contrastada. En concreto, los objetivosse pueden resumir en los siguientes puntos:

1. Conocer los tipos abstractos de datos y su aplicacion en contextos practicos

2. Elegir los TAD adecuados para la resolucion de un problema

3. Aplicar distintos algoritmos fundamentales relacionados con los TAD

4. Aprender a realizar distintas implementaciones sobre los principales TAD

5. Adquirir actitud crtica sobre los TAD bajo criterios de eficiencia

6. Aprender a resolver un problema bajo restricciones contractuales

7. Aprender a probar exhaustivamente una solucion orientada a objetos

En cuanto a la estructura del resto del documento, la seccion 2, Descripcion del

Problema, en la pagina 5, describe el problema que se desea resolver de forma deta-llada y que trata de implementar la emulacion de un sistema de ficheros completosimilar a los utilizados por el sistema MS-DOS. Una vez enunciado el mismo, se dis-cute la coleccion de artefactos de Java que compondran el desarrollo de la misma.Puede encontrarse un diagrama en UML, una descripcion del codigo y las expli-caciones pertinentes sobre el mismo en la seccion 3, en sus apartados 3.1 y 3.2.La seccion 4 continua proporcionando el plan de trabajo con las actividades queel alumno debe llevar a cabo para completar su practica. La seccion 5 describe lasnormas y fechas importantes para la entrega. Por ultimo, la seccion 6 detalla lasreferencias importantes para entender el enunciado y su desarrollo.

-4 -EPED curso 2.011-12 Enunciado de la Practica

7/30/2019 Pract e Ped 2012

5/23

2 DESCRIPCION DEL PROBLEMA

2. Descripcion del Problema

En la arquitectura de ordenadores de von Neumann, los datos se persisten en sis-temas de almacenamiento secundarios (tpicamente conocidos como discos duros).En este contexto, una parte nuclear de los sistemas operativos es el sistema deficheros, que proporciona una abstraccion de alto nivel que permite manejar losdatos de un disco en terminos de ficheros y directorios a partir de una coleccionde comandos accesibles al usuario. En las siguientes subsecciones, describimos losniveles de operacion en los que trabaja un sistema de ficheros similar a MS-DOSa.

2.1. Organizacion fsica del disco en clusters

Un disco se divide fsicamente en bloques de datos contiguos llamados clusters, queel computador es capaz de leer o escribir. Los clusters pueden contener datos, estar

vacos o, incluso, estar danados por motivos cualesquiera, aunque este ultimo casono se tendra en cuenta en esta practica. El aspecto, enfocado a bajo nivel, de undisco duro se muestra en la figura 1.

A = pista

B = sector geometricoC = sector de pistaD = cluster

Figura 1: Estructura de un disco duro ( c WikiMedia Commons)

Cuando se da formato a un disco, es preciso determinar en funci on de su tamano,cual es el numero de clusters que contendra as como el tamano de cada cluster,de manera que se cumpla la relacion de tamano(disco) = numero de clusterstamano del cluster. Adicionalmente, el proceso de formateo escribe el valor 0 encada byte del disco.

2.2. La Tabla de Asignacion de Ficheros

El trabajo a nivel de cluster sera en extremo arduo y tedioso para el usuario por loque, como se vera mas adelante, el sistema operativo ofrece la metafora de fichero

aA lo largo de este documento, se precisar an las diferencias con este sistema


7/30/2019 Pract e Ped 2012

6/23

2.2 La Tabla de Asignacion de Ficheros 2 DESCRIPCI ON DEL PROBLEMA

como una coleccion contigua de datos que se almacena bajo un nombre com un.

Segun lo expuesto, la responsabilidad del sistema de ficheros es ocultar la comple-

jidad de la organizacion de los datos en disco para ofrecer una perspectiva basadaen dicha metafora. En efecto, los datos de un fichero se persisten a nivel de dis-co como un conjunto de clusters, mientras que el fichero proporciona la ilusion decontiguidad.

Figura 2: Disposicion de ficheros en disco duro (FAT)

El artefacto del sistema operativo que sirve de puente de union entre la organizacionfsica en clusters y la metafora de fichero se conoce con el nombre de Tabla deAsignacion de Ficheros o FAT, por sus siglas en ingles. De esta manera, al escribirun fichero en disco, este se almacena en tantos clusters como sean necesarios segunsu tamano. Para ello, el sistema de ficheros solicita un cluster libre a la FAT dondecomienza a escribir dichos datos. Si el volumen de datos sobrepasa el tama no deun cluster, se le solicitara otro nuevo donde se continuara con la escritura. Dadoque los datos del fichero no tienen por que ser un multiplo entero del tamano de uncluster, es muy probable que el ultimo cluster se quede a medio llenar. Para marcaren esta circunstancia el final de los datos utiles del fichero, se utiliza un caracter

especial conocido como EOF.Para articular la gestion de clusters libres y ocupados del disco, la FAT utiliza unaestructura de datos interna que mantiene informacion sobre el enlace de contiguidadde los clusters que constituyen cada fichero. Esta es una estructura de datos linealy ordenada en la que el elemento i-esimo representa el i-esimo cluster del disco. Elvalor almacenado en cada entrada es una referencia al cluster donde continuan losdatos del fichero persistido en ese cluster. Si se trata del ultimo cluster con datosde un fichero, su valor en la FAT sera -1. Si el cluster esta libre, su valor en la FATsera 0.

Como se puede observar en el ejemplo de la figura 2, en el primer cluster de la FATcomienza un fichero que continua en el cluster 1 y termina en el 6. A su vez, enel cluster 3 comienza un segundo fichero que ocupa todos los clusters consecutivos


7/30/2019 Pract e Ped 2012

7/23

2 DESCRIPCION DEL PROBLEMA 2.3 Directorios y Ficheros

hasta el 5. Finalmente, el cluster 7 contiene otro fichero que continua y termina enel cluster 8, mientras que los clusters 9 y 10 estan libres.

La FAT siempre comienza prescriptivamente en el cluster 0 del disco y debe ocu-par tantos clusters como sea necesario para poder contener referencias a todos losclusters del disco. Como hemos dicho antes, esto depende del tamano del disco yde los paramtros de formateo, en particular, del numero de clusters. Por ejemplo,para un disco de 200 MBytes con un tamano 4096 de cluster en bytes, salen untotal de 51200 clusters. La mnima anchura de palabra que da cobertura en binarioa este ultimo valor es de k = 16 bits, lo que deja un tamano de FAT de al menos216 entradas, lo que se traduce, en virtud del tamano del cluster, en 16 clusters.

2.3. Directorios y Ficheros

Como ya se dijo en secciones anteriores, los sistemas operativos ofrecen una abstrac-

cion de alto nivel sobre la disposicion anterior en clusters basada en las metaforasde fichero y directorio, que se definen como sigue:

Un fichero es una secuencia de datos cualquiera persistido bajo un nombre enalgun medio de almacenamiento secundario y que puede moverse a la memoriaprincipal para su uso. Las operaciones principales que se pueden realizar sobreellos son las de lectura o escritura de los datos que contiene.

Un directorio o carpeta es un contenedor virtual que agrupa una coleccion deficheros y directorios, que permiten al usuario crear una compartimentacionde los contenidos del disco duro en forma de una estructura jer arquica, queparte de un unico directorio llamado principal o raz. Este directorio raz serefiere como / desde la consola del usuario e igualmente la operaci on denavegacion sobre la estructura jerarquica es el operador /, de tal maneraque mediante la concatenacion de nombres de directorios separados por /se establece la ruta (path) de acceso a la informacion. Por ejemplo, la ruta/usr/bin/java nos llevara al fichero llamado java, que esta en un directoriollamado bin, dentro de otro directorio usr, incluido en el raz. En esta practicano existen rutas relativas, por lo que no estan definidos los operadores . y.., tpicos de otros sistemas.

Para dar soporte a la organizacion jerarquica de directorios descrita anteriormente,se utiliza un artefacto llamado tabla de directorios. El sistema de ficheros mantieneuna de estas tablas por cada directorio que contiene informacion sobre los ficherosy directorios que este contiene. La estructura de esta tabla es una secuencia orde-

nada de entradas de directorio (DirEntry) con una longitud fija de 15 bytes, con lasiguiente estructura:

Nombre del recurso: 12 bytes. Contiene el nombre bajo el que se almacenael recurso. En este sistema no se considera obligatorio ni se distingue el usode extensiones a diferencia de otros como MS-DOS.Notese que esta longitudlimita los nombre de ficheros a 12 caracteres.

Tipo: 1 byte. Permite diferenciar ficheros y directorios. Un fichero se codificacomo f y un directorio como d.

Primer cluster del recurso: 2 bytes. Senala el numero de cluster en el quecomienza el fichero o la tabla de directorios si el tipo era d.


7/30/2019 Pract e Ped 2012

8/23

2.4 Comandos del Sistema de Ficheros 2 DESCRIPCION DEL PROBLEMA

Como se puede apreciar, las tablas de directorios no solo sirven para dotar de unnombre identificativo a los recursos del sistema sino que, adicionalmente, consti-tuyen el punto de enlace con la FAT, ya que cada entrada incluye el cluster de

comienzo del recurso que esta representa. Notese que el tamano reservado para esteultimo campo condiciona el numero de clusters que se pueden direccionar y, por lotanto, el tamano de la FAT hasta un total de 216 clusters.

2.4. Comandos del Sistema de Ficheros

Sobre estas abstracciones, construiremos una coleccion de comandos que permitanmanejar los ficheros mediante la consulta y manipulacion adecuadas de la tabla dedirectorios y, en ultima instancia, de la FAT, que son la estructura principal queinteresa a esta practica. Para ello, se usara un interprete de comandos o consola delque trataremos mas adelante. Dichos comandos admiten, en primer lugar, parame-tros posicionales (uno o mas, segun sea el comando) y opciones que comienzan por

el signo y modifican, si aparecen, el efecto del comando. Todos los parametrosposicionales de los comandos que se refieran a rutas deberan interpretarse comorutas absolutas hacia una ubicacion sobre la que se debera aplicar dicho comando.Esas rutas pueden especificar nombres de ficheros o de directorios. El efecto delcomando sera, por lo general, diferente dependiendo del objeto al que conduzcadicha ruta. Los comandos a los que se quiere dar servicio en esta pr actica se listana continuacion:

cat concatenate - concatena ficheros

SINTAXIS

cat pathFile -o

cat pathFile1 pathFile2 pathFile3

Con la opcion -o, concatena el contenido del fichero recibido como argumentoa la salida estandar, es decir, lista por la salida estandar el contenido de unfichero. Notese que su parametro debe ser un fichero.

Sin opciones, concatena el contenido del fichero pathFile2 al (final del) conte-nido del fichero pathFile1 y lo guarda en el fichero pathFile3

OPCIONES

-o vuelca por la salida estandar.

-h Muestra la ayuda del comando

cp copy - copia ficheros

SINTAXIS

cp sourcePath destPath [options]

Copia el contenido del recurso origen (cuya ruta es sourcePath) en la rutadestino (destPath). Notese que origen y destino pueden ser:

Dos ficheros, en cuyo caso copia el primero en la ruta del segundo, sobre-escribiendo este ultimo si exista y creandolo como nuevo si no exista.

Un fichero y un directorio, en cuyo caso copia el primero dentro del direc-torio que aparece como segundo.

Dos directorios, en cuyo caso, copia recursivamente del origen al destino.

OPCIONES


du display usage - muestra el espacio que ocupa un fichero o directorio

SINTAXIS


7/30/2019 Pract e Ped 2012

9/23

2 DESCRIPCION DEL PROBLEMA 2.4 Comandos del Sistema de Ficheros

du path [option]

Informa sobre el espacio que ocupa el fichero o directorio definido por suparametro. Si dicho parametro es un fichero, se lista el espacio que ocupa.

Si se trata de un directorio, se lista cada nombre de fichero junto con elespacio que ocupa y, al final, se lista el espacio acumulado. No tiene encuenta los subdirectorios.

OPCIONES

-a Si path es un directorio, muestra recursivamente el espacio que ocupacada fichero y subdirectorio, lo que se tiene en cuenta para el acumulado.


dump dump - vuelca contenido aleatorio en un fichero

SINTAXIS

dump path -n num

Crea un fichero que contiene num bytes producidos de forma aleatoria y

que no incluyen la marca de fin de fichero EOF.OPCIONES

-n Indica que el siguiente parametro nominal representa un numero debytes con los que rellenar el fichero que representa el parametro posicional.


ls list - lista informacion sobre ficheros y directorios

SINTAXIS

ls path [option]

Lista los ficheros y directorios de la ruta path si esta es un directorio. Si laruta es un fichero, lista el fichero (nombre y tamano).

OPCIONES

-d Lista solo los directorios

-r Lista el contenido de directorios y subdirectorios recursivamente-s Incluye el tamano de cada fichero


mkdir make directory - - crea directorios

SINTAXIS

mkdir path [option]

Crea un directorio. Si alguno de los directorios antecesores en la ruta no existe,provoca un error.

OPCIONES


rm remove - elimina ficheros o directorios

SINTAXIS

rm path [option]

Borra ficheros o directorios. Si el parametro identifica la ruta de un directorioque no esta vaco, no lo borra.

OPCIONES

-f Borra recursivamente directorios aunque no esten vacos.


Todos estos comandos representan las utilidades disponible para el usuario del sis-tema de ficheros. Ademas, de cara a esta practica, suponen una herramienta parala prueba de la implementacion de los distintos niveles de abstraccion sobre los quese apoyan.


7/30/2019 Pract e Ped 2012

10/23

3 DESARROLLO DE LA PRACTICA

3. Desarrollo de la practica

Con el animo de reducir la carga de trabajo del alumno y de mantener el desarrollode la practica alineado con los aspectos teoricos de la asignatura, se proporciona unainfraestructura de clases que modelan el problema descrito en la seccion anterioren orientacion a objetos y utilizando los TAD estudiados a lo largo del curso. Paraarticular esta idea, el codigo se organiza en torno a dos tipos de artefactos:

Codigo cerrado (vease el apartado 3.1 en la pagina 13), que es aquel que elEquipo Docente ofrece como andamiaje de soporte del trabajo del alumno.Este codigo no debe modificarse y por tanto se ofrece compilado.

Codigo abierto (vease el apartado 3.2 en la pagina 15), que es aquel que elalumno debe modificar y completar para realizar sus tareas en el marco de lapractica.

es.uned.lsi.practica.1112

src

main

java

eped

filesystem

os

fs

cmd

tads

resources

doc

testjava

resources

target

main

java

resources

test

lib

Figura 3: Contenido del proyecto de desarrollo de la practica

El alumno debe comprometerse a respetar dicha estructura desarrollando el codigodentro del marco tecnologico proporcionado y haciendo uso exclusivo de los TADestudiados en la asignatura. Todo este codigo se encuentra en el recurso practi-ca2012.zip, que se puede descargar desde el curso virtual y contiene un proyectocon todos los elementos necesarios para realizar la practica. Una vez descomprimi-do e incorporado a su entorno de desarrollo el aspecto debera ser el mostrado enla figura 3. El codigo fuente de las clases abiertas aparecera dentro de la carpetasrc/main/java. Las documentacion de las API (en formato javadoc), tanto de lasque se utilizan en la practica como las propias de los TAD, aparecen en la carpetasrc/main/resources/doc. En la carpeta test/java, el alumno puede incluir los juegosde pruebas que considere oportunos. La carpeta target debera incluir los artefactoscompilados de la practica (ficheros con extension . class). Finalmente, la carpeta


7/30/2019 Pract e Ped 2012

11/23


/lib contiene los jar tad.jar y filesystem.jar que incluyen el c odigo de las interfacesde los TAD de la asignatura y el c odigo de las clases cerradas de la practica respec-tivamente. A continuacion, detallamos mas detenidamente las responsabilidades de

los artefactos que aparecen en la arquitectura de la practica:

1. El paquete eped.filesystem. El proyecto de la practica contiene una coleccionde clases java, dentro del paquete filesystem, que se corresponden parcialmentecon la modelizacion del problema descrito en la seccion 2, que comienza en lapagina 5. De estas clases se proporciona su codigo fuente para que sea editado(modificado y completado) por el alumno. En torno a estos recursos giran lasactividades descritas en la seccion 4 de la pagina 17

2. El paquete eped.tads, inicialmente vaco, debera contener al final de la reali-zacion de la practica una coleccion de clases en forma de codigo fuente que secorresponden con la implementacion de aquellas interfaces de los TAD estudia-dos en la asignatura, que el alumno haya necesitado para la implementacion

de esta practica. Aunque no lo recomendamos, el alumno puede hacer unaimplementacion adaptada al problema de la practica de estos tipos abstractosextendiendo o alterando su comportamiento. Pero nada de esto debe ir encontra de la semantica establecida en el contrato de las interfaces de los TAD.Ademas, queda terminantemente prohibido el uso de las clases de utilidad deJava (java.util.*) para implementar los TADs que describen estas interfaces.

3. El jar filesystem. En la carpeta lib del proyecto, aparece el fichero filesys-tem.jar que contiene el paquete es.uned.lsi.eped.filesystem con la coleccion deinterfaces y clases cerradas que implementan la otra parte de la descripciondel problema. Notese que las clases de este paquete se referenciaran en laimplementacion de las clases de c odigo abierto del paquete eped.filesystemdescrito en el punto 1 de esta enumeracion.

4. El jar tads. Tambien en la carpeta lib, se encuentra el fichero tads.jar que con-tiene las interfaces de todos los tipos abstractos de datos estudiados duranteel curso y cuya implementacion debera ser realizada por el estudiante en elpaquete eped.tads, tal y como se ha descrito en el punto 2 de esta enumeracion.

5. Documentacion. Finalmente, es de destacar la aparicion de toda la documen-tacion de las APIs de la practica en formato javadoc. Recomendamos quemantenga abierta esta documentacion en un navegador mientras implementala practica para tener acceso a la forma de los contratos de todas las clases einterfaces de los TAD y de la practica.

En las dos siguientes subsecciones, describiremos cada uno de los elementos quepueden encontrarse en el proyecto como codigo cerrado y como codigo abierto res-pectivamente. Recomendamos que la lectura de estas dos subsecciones se relice enparalelo siguiendo la estructura de paquetes incluida en cada una de ellas. Antesde finalizar, no obstante, se ofrece un diagrama de clases de diseno en UML (figu-ra 4 en la pagina 12) que representa graficamente estos elementos y las relacionesestructurales entre ellos.


7/30/2019 Pract e Ped 2012

12/23


Figura 4: Diagrama de clases de diseno de la practica


7/30/2019 Pract e Ped 2012

13/23

3 DESARROLLO DE LA PRACTICA 3.1 Codigo cerrado

3.1. Codigo cerrado

Tal y como hemos dicho, las clases de codigo cerrado que se proporcionan inicialmen-

te en el proyecto son aquellas contenidas en el paquete es.uned.lsi .eped.filesystem.A continuacion, describimos el contenido de cada uno de estos paquetes.

3.1.1. Paquete es .uned. lsi .eped.filesystem . disk

Este paquete representa una abstraccion sobre la organizacion fsica de los datos enun dispositivo de almacenamiento secundario o disco y pretende facilitar el accesoa estos segun se persisten en dicho disco pero desde un punto de vista cercano aldel hardware.

En este nivel, la organizacion de un disco se establece respecto a unidades de datosllamadas clusters, que representan conjuntos contiguos de datos relacionados por

ser parte de un mismo recurso. Como se explico en el apartado 2 (vease la pagina 5),un disco se compone de un cierto numero de clusters, que suponen la linealizacionde todo el espacio con que dicho dispositivo cuenta para almacenar informacion.

Los artefactos que comprende este paquete son:

Interfaz DiskIF. Respresenta el disco y esta constituido por una coleccioncontigua de clusters. Ofrece metodos para cargar y guardar el contenido deldisco en un fichero, aunque estas operaciones no son imprescindibles paradesarrollar la practica.

Clase Disk. Es una implementacion de la interfaz anterior. Su constructorincorpora la logica que permite crear esa coleccion en funcion de un numerode clusters y el tamano de los mismos.

Interfaz ClusterIF. Constituye el contrato programatico de un cluster, es decir,aquellas operaciones que toda implementacion de dicha entidad debe cumplir.Sus metodos permiten fundamentalmente, volcar y recuperar datos en el clus-ter. Asimismo, en esta interfaz se define la constante EOF, que identificael final del contenido de un fichero en aquellos clusters que sean cola de lasecuencia de datos que componen el mismo.

Clase Cluster. Es una implementacion de la interfaz descrita anteriormente.

3.1.2. Paquete es .uned. lsi .eped.filesystem .os

Este paquete representa una abstraccion sobre el disco, que permite gestionar yorganizar los clusters del nivel anterior enlazandolos con el concepto de recurso(ficheros y directorios) propios de los niveles superiores de la practica (descritosmas adelante).

Los artefactos de este paquete son:

Interfaz FATIF. Representa el contrato programatico de cualquier implemen-tacion de una FAT. Sus metodos principales permiten realizar operacionessobre secuencias enlazadas de clusters tales como recorridos, reservas y libe-raciones.

Interfaz DirTableIF. Constituye el contrato programatico de toda implemen-tacion de una Tabla de Directorios. Una Tabla de Directorios es un artefacto


7/30/2019 Pract e Ped 2012

14/23

3.1 Codigo cerrado 3 DESARROLLO DE LA PR ACTICA

que gestiona la coleccion de entradas que representan los recursos que se en-cuentran logicamente contenidos en un directorio. Los metodos principales deesta interfaz permiten modificar estos atributos y recuperar, anadir y eliminar

elementos de esta coleccion.

Interfaz DirEntryIF. Cada uno de los recursos que aparecen en una Tabla deDirectorios, se describe a partir de una coleccion de atributos (nombre, tipo,etc.). La DirEntry es el artefacto que recoge esta coleccion de atributos. Estainterfaz representa el contrato programatico de toda implementacion de unaDirEntry. Sus metodos principales permiten obtener o establecer valores delos atributos de un recurso.

Clase DirEntry. Es una implementacion de la interfaz anterior.

3.1.3. Paquete es. uned. lsi .eped.filesystem . fs

Este paquete constituye una abstraccion sobre el anterior nivel (os) y representa losartefactos de alto nivel fichero (File) y directorio (Directory). Los artefactos de estepaquete son:

Interfaz FileManagerIF. Representa el contrato programatico del FileMana-ger. Entre las responsabilidades que prescribe esta interfaz estan la carga yla salvaguarda de los datos de un fichero, abstrayendo de la existencia declusters.

Interfaz DirectoryManagerIF. Representa un contrato para la implementaciondel DirectoryManager. Este artefacto permite la organizacion jerarquica de losficheros del sistema en una estructura de directorios y subdirectorios, para locual proporciona capacidades de creacion, consulta, modificacion y borrado de

directorios as como la adicion y eliminacion de ficheros dentro de los mismos.

Interfaz ResourceIF. Un recurso es una abstraccion que representa de formageneral cualquiera de los elementos que se pueden contener en un directorio.Esta interfaz constituye un contrato para este artefacto.

Clase Resource. Constituye una representacion comun de ficheros y directoriosy es una implementacion abstracta de la interfaz ResourceIF.

Clase File. Mediante esta abstraccion de alto nivel, los datos enlazados enclusters reciben un nombre para que puedan ser referidos por los comandos.Esta clase es un subtipo de la clase Resource.

Clase Directory. Mediante esta abstraccion, los recursos del sistema de fiche-

ros se pueden organizar de forma jerarquica. Esta clase es el otro subtipo deResource.

3.1.4. Paquete es .uned. lsi .eped.filesystem .cmd

Este paquete contiene un conjunto de artefactos que permiten ejecutar una serie deacciones de modificacion y consulta al usuario final sobre los recursos del sistemade ficheros. Los artefactos de este paquete son:

Interfaz CommandIF. Representa el contrato programatico de cualquier im-plementacion de un comando del sistema. En esencia, contiene un metodo quepermite la ejecucion del mismo.


7/30/2019 Pract e Ped 2012

15/23

3 DESARROLLO DE LA PRACTICA 3.2 Codigo abierto

Clase Command. Es una clase abstracta que implementa la interfaz CommandIFy que, a su vez, sirve de base para la implementacion de comandos especficos.

Interfaz CommandFactoryIF. Esta interfaz define un contrato para la imple-mentacion de artefactos que permiten crear comandos especficos por mediode una representacion textual de los mismos.

Clase CommandFactory. Implementa la interfaz CommandFactoryIF anterior.

3.1.5. Paquete es. uned. lsi .eped.filesystem

Este es el paquete padre que contiene todo el resto de paquetes anteriormente descri-tos. Adicionalmente, incluye una clase de uso general, que se describe a continuacion:

Clase FilesystemContext. Esta clase proporciona acceso directo a los artefac-tos de caracter unico que se utilizan a lo largo del desarrollo de la practica. Enparticular, nos referimos a la FAT, el FilesystemManager y al DirectoryManager.El constructor de esta clase recibe como argumento el disco sobre el cual seva a montar el sistema de ficheros. Atencion: es muy importante que seconstruya un unico objeto de esta clase para proporcionar un solo accesoa los tres artefactos anteriormente descritos y as evitar pervertir el correctofuncionamiento del sistema.

3.2. Codigo abierto

Tal y como hemos dicho, las clases de codigo abierto que se proporcionan inicialmen-te en el proyecto son aquellas contenidas en el paquete eped.filesystem. La imple-

mentacion de las clases de codigo abierto contenidas en este paquete complementana las de codigo cerrado (vease el apartado 3.1 en la pagina 13) para proporcionar unfuncionamiento coherente y completo al sistema. Este paquete contiene las tareasde implementacion que debe realizar el alumno y, por tanto, la mayora de la des-cripcion de las clases subsiguientes contiene sugerencias, pistas y consejos relativosa las dependencias de caracter estructural que se dan entre dichas clases.

3.2.1. Paquete eped.filesystem . os

Clase FAT. Representa una implementacion de la interfaz FATIF y organizala coleccion de clusters enlazados de los recursos en una estructura internaen memoria para facilitar su gestion. La implementacion de esta clase debepresentar una dependencia de uso con el Disco, ya que trata con los clustersalmacenados en este.

Clase DirTable. Representa una implementacion de la interfaz DirTableIF yse corresponde con la estructura de Tabla de Directorios de un sistema deficheros, que fue descritta en el apartado 3.1. En tanto que este artefactogestiona una coleccion de entradas de directorio, debe existir una relacioncompositiva entre esta clase y la clase DirEntry.

3.2.2. Paquete eped.filesystem . fs

Clase FileManager. Como se dijo en el apartado 3.1.3 de la pagina 14, estaclase es la implementacion de la interfaz FileManagerIF y debe permitir la


7/30/2019 Pract e Ped 2012

16/23

3.2 Codigo abierto 3 DESARROLLO DE LA PR ACTICA

carga y salvaguarda de los datos de un fichero. Esto impone la necesidad demantener una relacion de uso con la clase FAT. Asimismo, necesita mantenerseuna relacion de uso con la clase DirectoryManager para localizar los ficheros

sobre los que trabaja.

Clase DirectoryManager. Implementa la interfaz DirectoryManagerIF, que seexplicaba en el apartado 3.1.3, y que gestiona la estructura jerarquica dedirectorios del sistema de ficheros. Para ello, mantiene una estructura internaen memoria que representa todo el arbol de directorios y hace uso de la claseFAT para acceder a los clusters del disco donde residen los recursos. Estaestructura interna debe ser prescriptivamente un arbol de objetos DirEntry yno debe ser substituida por ninguna otra por parte del alumno.

3.2.3. Paquete eped.filesystem . cmd

Existe un conjunto de clases que extienden Command (vease 3.1.4 en la pagina 14)y que representan los distintos comandos que puede ejecutar el usuario.

Estas clases son:

CommandCat

CommandCp

CommandDu

CommandDump

CommandLs

CommandMkdir

CommandRm

La descripcion del funcionamiento de dichos comandos puede encontrarse en elapartado 2.4. La clase CommandCp se da implementada a modo de ejemplo ygua. Ademas, este paquete incluye la clase Console que constituye una interfaz deusuario para facilitar la prueba simulando una lnea de comandos. Si desea salir deesta, utilice el comando quit. En principio, esta clase no debe modificarse pero seproporciona como codigo abierto por si el alumno desease realizar modificaciones.


7/30/2019 Pract e Ped 2012

17/23

4 PLAN DE TRABAJO

4. Plan de trabajo

Para realizar la practica, el alumno debera llevar a cabo una serie de actividades quese detallan a continuacion. Para cada una de ellas, habra que realizar un conjuntode tareas, que estan reflejadas en el codigo mediante comentarios similares al queaparece en la figura 5. Como puede apreciarse, toda tarea comienza por la palabraclave TODO seguida de un codigo entre corchetes que indica el numero de la actividady el numero de tarea dentro de la misma, separados por . y finalizado por el mensajeTrabajo del estudiante y, en las lneas subsiguientes, la descripcion de latarea. El uso de IDEs como Eclipse, NetBeans o IntelligentJ ayuda a localizar esteconjunto de tareas facilmente. Se recomienda que el alumno, segun vaya terminandolas tareas en el orden que se indica, vaya borrando los comentarios // TODO :Trabajo de estudiante .

// TODO [1.03]: Trabajo de estudiante

// A partir de la estructura de datos decidida

// para la FAT debe ser posible siempre devolver

// el siguiente cluster al dado como parametro

// que forma parte de un recurso. Recuerde que

// si u n c luster e s e l ultimo de un recurso su

// siguiente en la FAT escrita en disco esta

// marcada con un LAST_CLUSTER. Tenga en cuenta

// que el primer cluster libre de un disco vaco

// va justo detras de los clusters dedicados a la

// FAT y a la dirTable del directo raz.

Figura 5: Modelo de comentario que describe una tarea

4.1. Actividad 0. Instalacion y preparacion del entorno

El paso preliminar para comenzar con la realizacion de la practica requiere prepararel entorno de desarrollo e instalar todo el software necesario. Sus fases son lassiguientes:

1. Instalacion del lenguaje Java. La practica de esta asignatura se desarrollasobre la plataforma JSE de Java. Para realizarla es necesario que instale el kitde desarrollo JDK que puede descargar de la direccion web descrita en [Java].Recomendamos que seleccione la ultima version de Java y nunca una anterior

a la version 1.6 (Mustang). Siga la secuencia de instrucciones del programainstalador y si es necesario, establezca la variable de entorno CLASSPATHpara que apunte al directorio en curso (.) y al directorio /lib donde hayainstalado Java (si su ordenador ya dispone de una instalacion de Java, omitaeste paso).

2. Instale un entorno de desarrollo (IDE). Seleccione el entorno de desarrollointegrado que mas le agrade e instalelo en su sistema. Existen disponiblesen Internet varios de estos entornos y desde esta asignatura no pretendemosinclinarnos por ninguno de ellos. Puede seleccionar [BlueJ] que es un entornopreparado para la educacion y que se utiliza en otras asignaturas de este gradoen la UNED o puede decantarse por herramientas de caracter profesional como[Eclipse], [NetBeans] o [IntelligentJ].


7/30/2019 Pract e Ped 2012

18/23

4.2 Actividad 1. Desarrollo de la FAT 4 PLAN DE TRABAJO

3. Instale la infraestructura de clases para la practica. Para desarrollar la practicase proporciona la coleccion de clases que fueron descritas en la seccion 3 deeste documento. Descargue del entorno virtual todo el codigo necesario para

la practica y genere un proyecto con ella en su entorno de desarrollo.

4.2. Actividad 1. Desarrollo de la FAT

La primera actividad consiste en la realizacion de la FAT. Esta actividad requierela eleccion de un TAD para la FAT. Recuerdese que la FAT contiene una coleccionde clusters y que cada recurso (directorio o fichero) se almacena en una secuenciaenlazada de clusters, por lo que la FAT contendra una coleccion de secuencias declusters. Edite la clase abierta FAT perteneciente al paquete eped.os, inspeccione elcodigo y lleve a cabo las tareas all descritas.

4.3. Actividad 2. Desarrollo de la DirTable

La segunda actividad consiste en la implementacion de la clase DirTable que re-presenta una Tabla de Directorio. Es decir, que recoge la informaci on sobre todoslos ficheros y directorios que contiene el directorio al que representa dicha tabla.La DirTable contendra una coleccion de entradas (DirEntry), que representan alos ficheros y directorios antedichos. Edite la clase abierta DirTable en el paqueteeped.os y complete las tareas all descritas.

4.4. Actividad 3. Desarrollo del FileManager

La tercera actividad consiste en la implementacion del FileManager: un gestor deficheros que constituye la fachada entre los paquetes eped.fs y eped.os. Esta clasefacilita trabajar con el segundo paquete desde el primero elevando el nivel de abs-traccion. Edite la clase abierta FileManager y realice las tareas que all se detallan.

4.5. Actividad 4. Desarrollo del DirectoryManager

La cuarta actividad trata de la implementacion del DirectoryManager, es decir, ungestor de directorios que representa la fachada para operaciones con recursos (di-rectorios y ficheros) entre los paquetes eped.fs y eped.os. El DirectoryManager es elencargado de la estructuracion jerarquica de los directorios del sistema de ficherosy tiene como responsabilidades las operaciones de alta, baja, localizaci on y deter-

minacion del tipo de recurso, entre otras. Notese que, para mantener la estructurade arbol de directorios, se utiliza un atributo privado filesystem declarado comoTreeIF. Esta estructura debe ser utilizada sin cambiarla. Edite la clase abiertaDirectoryManager perteneciente al paquete eped.fs y realice las tareas que all sedetallan.

4.6. Actividad 5. Implementacion de comandos

La ultima actividad tiene por objetivo la implementacion de un conjunto de co-mandos de usuario mediante la utilizacion de la arquitectura subyacente que sedebera haber implementado en las actividades anteriores. Cada uno de los coman-dos trabaja con ficheros y directorios, por lo que se deber an usar las clases cerradas


7/30/2019 Pract e Ped 2012

19/23

4 P LAN DE TRABAJO 4.6 A ctividad 5. Implementacion de comandos

File y Directory que encapsulan estas entidades para realizar las operaciones ade-cuadas a cada comando y ninguna otra clase mas. La logica de los mismos debereproducir fielmente la que esta descrita en el apartado 2.4 de la p agina 8 y consi-

derar tanto los flujos principales (el desarrollo normal de cada comando) como losalternativos y los potenciales errores en la ejecucion de dichos comandos. Cada unode los comandos se corresponde con una subclase de la clase cerrada Command ycumple la interfaz CommandIF.

En cuanto a las tareas de esta actividad, el Equipo Docente proporciona implemen-tado el comando CommandCp como codigo abierto para que el alumno lo utilicecomo gua de implementacion de los demas. Edite las clases abiertas correspon-dientes a los distintos comandos pertenecientes al paquete eped.cmd, inspeccione elcodigo que ofrece el Equipo Docente e implemente las tareas que se recogen all.


7/30/2019 Pract e Ped 2012

20/23

5 EVALUACION Y CALENDARIO DE ENTREGA

5. Evaluacion y calendario de entrega

5.1. Fases de la realizacion de la practica

Para llevar a cabo la practica, el alumno debera seguir las siguientes fases de desa-rrollo, si bien algunas de ellas, no necesariamente tienen por que realizarse en elorden en que se detallan a continuacion:

1. Asistencia a la sesion de control obligatoria. Durante el desarrollo del cua-trimestre, tendra lugar en los centros asociados de la UNED una sesion decontrol con caracter orientativo y asistencia obligatoria para aprobar la asig-natura. Pongase en contacto con su tutor o Centro Asociado para conocer lafecha de celebracion de estas sesiones.

2. Implementacion de la practica segun las instrucciones de este documento.

3. Entrega del codigo al Tutor, que sera el encargado de evaluar la la practica,en la forma y tiempo que este prescriba segun el calendario marcado por el.

4. Entrega del codigo al Equipo Docente mediante el entorno virtual.

5.2. Fechas de entrega

La evaluacion de la practica implica los cuatro pasos que deben ser satisfechos paraaprobarla. Cada uno tiene una fecha concreta para su realizaci on. En particular, lafecha de los 3 primeros pasos la establece el Tutor de su Centro Asociado. P onga-se en contacto con el para obtener informacion al respecto de este calendario. Elpaso 4 - el envo del codigo de la practica al Equipo Docente - se realizara te-

lematicamente a traves del entorno virtual de la asignatura mediante un enlace quepermanecera habilitado hasta el 22 de junio de 2012 para la convocatoria de junioy hasta el 14 de septiembre para la convocatoria extraordinaria. Cualquier cambioal respecto de esta planificacion inicial, tanto de retraso como adelanto, sera conve-nientemente publicado en el tablon de noticias de la asignatura, accesible desde elentorno virtual. Recomendamos al alumno que revise este tablon con frecuencia.

5.3. Evaluacion y calificacion

Segun aparece publicado en la normativa de la asignatura la evaluacion de la practicasupone un 20 % sobre el total de la nota final. Es decir, la nota del examen se ponderaen rango [0 . . . 10] al 80 % y la de esta practica en rango [0 . . . 10] al 20 % de manera

que: NotaFinal = 0,8NotaExamen + 0,2NotaPractica

Lo que se describe a continuacion es como se computa el valor de NotaPractica apartir del resultado de los pasos de evaluacion descritos en la subseccion 5.1. Des-cribiremos los factores que intervienen en la calificacion de forma aislada:

1. Sesiones de control [SC]. Para aprobar la sesion de control unicamente esnecesario que el Tutor registre la asistencia del alumno. Recomendamos queel alumno se asegure de este hecho ya que de no figurar como presentado en lamisma, la practica estara suspensa. De cara al computo numerico, considereque esta calificacion es 1 en caso de asistencia y 0 en caso contrario. El Centrosolo tiene obligacion de celebrar una sesion para cada grupo de alumnos enlos que divida sus matriculados y por cada curso academico.


7/30/2019 Pract e Ped 2012

21/23

5 EVALUACION Y CALENDARIO DE ENTREGA 5.4 Criterios de calificacion

2. Codigo de la practica [CP], que valorara el Tutor segun los criterios que pres-cribe el Equipo Docente.

A partir de esta informacion se pueden describir los criterios que asignan unacalificacion final a la nota de la practica por aplicacion de la siguiente formula:NotaPractica = SC CP

Donde deben cumplirse para computar la f ormula las siguientes restricciones:

SC = 1

CP 4

5.4. Criterios de calificacion

A continuacion se discuten algunos de los criterios mas relevantes de correccion quedeben ser tenidos en cuenta por el estudiante durante la realizacion de la practicapara la obtencion de una calificacion apta en la misma. Notese que no cumpliralguno de estos criterios puede suponer un suspenso automatico.

1. La realizacion de la practica tiene caracter obligatorio. No puede aprobarse laasignatura sin haber aprobado la practica.

2. La practica es individual. Las practicas cuyo codigo coincida significativamen-te con el de otro alumno seran motivo de suspenso para todos los implicados,no pudiendo aprobar ninguno de ellos en el presente curso academico.

3. El alumno debera implementar su practica utilizando, exclusivamente, losTAD explicados en el curso. Toda utilizacion de otras abstracciones o im-plementaciones (por ejemplo, las clases de utilidad que Java proporciona paralas estructuras lineales, o las estructuras propias del lenguaje) implicara el sus-penso inmediato de la practica con las consecuencias descritas en los puntos 1y 2. Aqu, naturalmente, nos referimos a las clases del paquete eped.filesystemy no a las implementaciones de TAD del paquete eped.tads.

4. Asimismo, las implementaciones que el alumno realice de los TADs necesariospara el funcionamiento de su practica deben ser normativamente incluidasdentro del paquete eped.tads. El uso de clases fuera de este paquete podra su-poner el suspenso de la practica.

5. El alumno debera cumplir con el protocolo y fechas de entrega descritas enlas subsecciones 5.1 y 5.2 de este documento. No se admitir an excepciones aesta norma, por lo que se recomienda una adecuada planificacion temporalas como la observancia de unas mnimas normas de seguridad inexcusables,que incluyen pero no se limitan a:

a) La conservacion de copias de seguridad en cantidad y medios que evitenproblemas de perdida o corrupcion del codigo, ya que no se contem-plara ni la exencion ni el aplazamiento debido a estos motivos. Recomen-damos al alumno que obtenga algun medio de almacenamiento en la redque complemente sus propias medidas y copias. Asimismo, nos permiti-mos recomendar que se estudie la instalacion y uso de algun sistema decontrol de versiones como [Subversion] o [Git]


7/30/2019 Pract e Ped 2012

22/23

5.4 Criterios de calificacion 5 EVALUACI ON Y CALENDARIO DE ENTREGA

b) La garanta de la ausencia de virus, troyanos, gusanos y cualquier otromalware o spyware. La deteccion de dichos elementos ajenos a la practicaprovocara el inmediato suspenso en los terminos que dictan los puntos 1

y 2 de este apartado.

El alumno debera consultar los foros de la asignatura (Foro de Practicas) y contactarcon el TAR o con su Tutor si tiene dudas sobre la practica. La puesta en comun deideas con los companeros a traves de los foros se permite y se aconseja, siempre queno lleve asociado el intercambio de codigo (vease el punto 2).


7/30/2019 Pract e Ped 2012

23/23

6 REFERENCIAS

6. Referencias

Java: http://www.java.com

BlueJ: http://www.bluej.org

Eclipse: {http://www.eclipse.org

IntelligentJ: {http://www.jetbrains.com/idea/}

NetBeans: http://www.netbeans.org

Subversion: http://subversion.tigris.org

Git: http://git-scm.com

pract e ped 2012

Documents