Estrategias de Programacin

y Estructuras de Datos
Grado en Ingeniera Informtica
Grado en Tecnologas de la Informacin

Prctica curso 2015-2016

Enunciado

ndice
1. Presentacin del problema................................................................................................................3
2. Diseo...............................................................................................................................................4
2.1 Tipos de datos de referencia.......................................................................................................4
2.2 Primer escenario: Academia con rbol Genealgico Simplificado..........................................6
Preguntas tericas (trabajo del estudiante)..................................................................................7
2.3 Segundo escenario: Academia con rbol Genealgico Completo............................................7
Preguntas tericas (trabajo del estudiante)..................................................................................9
3. Implementacin................................................................................................................................9
3.1 Parmetros de entrada..............................................................................................................10
3.2 Estructura del fichero de datos.................................................................................................10
3.3 Estructura del fichero de operaciones......................................................................................10
3.4 Medicin de tiempos................................................................................................................12
Estudio emprico del coste temporal (trabajo del estudiante)...................................................12
3.5 Salida del programa.................................................................................................................12
4. Ejecucin y juegos de prueba.........................................................................................................13
5. Documentacin y plazos de entrega...............................................................................................13

1. Presentacin del problema

Una Academia est formada por una serie de Doctores, que entran a formar parte de ella tras leer
una Tesis doctoral. stas se realizan de forma individual bajo la supervisin (o direccin) de un
director de Tesis (o varios codirectores), que tambin ha de ser doctor(es) de la Academia, salvo en
el caso del fundador de la misma, que pertenece a ella por derecho propio (sin necesidad de haber
realizado una Tesis doctoral dentro de la Academia).
En una Academia, las relaciones de direccin de Tesis doctorales conforman el llamado rbol
Genealgico Acadmico.

Muestra de relaciones en un rbol genealgico acadmico tomada de Wikipedia

(https://en.wikipedia.org/wiki/Academic_genealogy). La figura indica que Johannes de
Groot ha supervisado cuatro tesis doctorales: las de Pieter Baayen, Maarten Maurice,
Johannes Aarts y Aida Paalman-de Miranda. Se recogen tambin relaciones de doble
supervisin, que slo consideraremos en una segunda aproximacin al problema (ver
seccin 2.3, Academia con rbol genealgico completo). Por ejemplo, la tesis de Jan
Van Mill fue codirigida por Pieter Baayen y Eric van Douwen.
En esta prctica gestionaremos la informacin de una Academia, que ser construida a partir de su
fundador y de los datos de direccin de Tesis doctorales por parte de Doctores de la Academia.
Supondremos adems, para simplificar, que un Doctor slo podr realizar una nica Tesis doctoral
(en la prctica son muy pocos los casos en los que una misma persona hace ms de una).
Los objetivos principales de esta prctica son:

Comprender la implementacin de Tipos Abstractos de Datos (TAD)

Ejercitar el uso de TAD
Implementar nuevos TAD a partir de otros conocidos
3

Como objetivos adicionales, podemos destacar:

Familiarizarse con la definicin de interfaces de TAD

Implementar la solucin de un problema completo utilizando TAD en Java
Familiarizarse con la prueba de programas mediante la tcnica de Juegos de Pruebas
Familiarizarse con el uso de entornos de programacin (IDE)

2. Diseo.
En esta prctica trabajaremos con dos escenarios diferentes que condicionarn la eleccin (y, por
tanto, el manejo) de las estructuras de datos para almacenar la informacin de una Academia.
Siguiendo las instrucciones de este enunciado de prcticas, los estudiantes debern (i) razonar sobre
el coste de las soluciones a cada uno de los escenarios propuestos, de forma comparada; (ii)
implementar ambas soluciones; y (iii) realizar un estudio emprico de su eficiencia respecto al juego
de pruebas proporcionado por el equipo docente, al menos.

2.1 Tipos de datos de referencia.

En primer lugar debemos especificar la interfaz (el tipo de datos de referencia) para las posibles
estructuras de datos con las que representaremos la Academia.
Las operaciones que se realizan en un TAD se pueden agrupar bajo las siglas C.R.U.D.:

CREATE - Operaciones de creacin:

Contemplaremos una operacin de creacin que crear una nueva Academia a partir de
su fundador.
READ - Operaciones de consulta:
Una operacin que devuelva el Doctor que fund la Academia.
Una operacin que busque un Doctor dentro de la Academia a partir de un identificador
unvoco.
Una operacin que devuelva el nmero de Doctores que pertenecen a la Academia.
UPDATE - Operaciones de modificacin:
Una operacin que aada un Doctor a la Academia, a partir de la informacin de la
lectura de su Tesis Doctoral.
Una operacin que aada una relacin de supervisin al rbol Genealgico de la
Academia a partir de los Doctores que dicha supervisin relaciona.
DELETE Operaciones de borrado:
Dado que el grado de Doctor es permanente (salvo contadas excepciones) y por
simplicidad a efectos de esta prctica, no se aadir una operacin que elimine
informacin, aunque es un requisito bsico de toda estructura de datos.

Las operaciones de creacin se realizarn mediante constructores, cuya implementacin no

corresponde a una interfaz.
Una interfaz que responde a los requisitos para las operaciones de consulta y modificacin es la
siguiente:

/*RepresentacindeunaAcademiaformadaporunacoleccindeDoctores*/
publicinterfaceAcademiaIFextendsCollectionIF<DoctorIF>{
/*ConsultaelDoctorquefundlaAcademia*/
/*@returnselDoctorfundadordelaAcademia*/
publicDoctorIFgetFounder();
/*BuscaunDoctordentrodelaAcademiaapartirdesuidentificador*/
/*@preeldoctorpertenecealaAcademia&&id>0*/
/*@paramelidentificadordelDoctorabuscar*/
/*@returnselDoctorbuscado*/
publicDoctorIFgetDoctor(intid);
/*ConsultaelnmerodeDoctoresquepertenecenalaAcademia*/
/*@returnselnmerodeDoctorespertenecientesalaAcademia*/
publicintsize();
/*AadeunnuevoDoctoralaAcademiaapartirdelalecturadesuTesis*/
/*@paramelnuevoDoctorysuprimerdirectordeTesis*/
/*@preelnuevodoctornodebeperteneceralaAcademia&&*/
/*elsupervisorsdebeperteneceralaAcademia*/
publicvoidaddDoctor(DoctorIFnewDoctor,DoctorIFsupervisor);
/*AadeunarelacindedireccinalrbolGenealgicodelaAcademia*/
/*@paramelnuevoDoctoryunodesuscodirectoresdeTesis*/
/*@preambosdoctoresdebenperteneceralaAcademia&&*/
/*noexisteunarelacindesupervisinpreviaentreambos*/
publicvoidaddSupervision(DoctorIFstudent,DoctorIFsupervisor);
}

Esta interfaz hace uso de una interfaz DoctorIF, que se detalla a continuacin:
/*RepresentacindeunDoctorpertenecienteaunaAcademia*/
PublicinterfaceDoctorIF{
/*Consultalosancestrosacadmicosdeldoctor,limitndosealnmerode*/
/*generacionesindicadoporelparmetro.*/
/*@returnslacoleccindeancestrosacadmicosdeldoctorlimitadaal*/
/*nmerodegeneracionesindicadoohastallegaralfundadordela*/
/*Academia.Nodebercontenerrepeticiones.*/
/*@paramnmerodegeneracionesaconsiderar*/
/*@pregenerations>0*/
publicCollectionIF<DoctorIF>getAncestors(intgenerations);
/*ConsultalosdoctoresaquieneseldoctorhadirigidosusTesis.*/
/*@returnslacoleccindedoctorescuyodirectordetesiseseldoctor.*/
publicCollectionIF<DoctorIF>getStudents();
/*Consultalosdescendientesacadmicosdeldoctor,limitndosealnmero*/
/*degeneracionesindicadoporelparmetro.*/
/*@returnslacoleccindedescendientesacadmicosdeldoctorlimitada*/
/*alnmerodegeneracionesindicadoohastallegaraDoctoresqueno*/
/*hayandirigidoningunaTesis.Nodebercontenerrepeticiones.*/
/*@paramnmerodegeneracionesaconsiderar*/
/*@pregenerations>0*/
publicCollectionIF<DoctorIF>getDescendants(intgenerations);

/*Consultalosdoctoresquecompartendirectordetesisconeldoctor.*/
/*@returnslacoleccindehermanosacadmicosdeldoctor.Nodeber*/
/*contenerrepeticionesnialdoctorllamante*/
publicCollectionIF<DoctorIF>getSiblings();
}

Todas estas operaciones de consulta devuelven colecciones de Doctores en las que no podr haber
repeticiones (es decir, cada Doctor slo podr aparecer una nica vez). Adems, dado que los
mtodos devuelven colecciones de objetos DoctorIF, el orden de los diferentes objetos es
irrelevante.
Para poder identificar de manera unvoca a los diferentes Doctores de una Academia, cada uno de
ellos tendr asociado un nmero entero positivo nico dentro de la Academia. Es decir, no podrn
existir dos Doctores en la misma Academia que tengan el mismo identificador.

2.2 Primer escenario: Academia con rbol Genealgico

Simplificado.
Para simplificar, supongamos que una Academia se funda a partir de un nico primer Doctor. A
partir de ese fundador (que consideraremos origen del rbol genealgico de la Academia), nos
interesa disponer de un TAD que recoja la informacin de la Academia, esto es, la coleccin de
Doctores que la forman y la informacin genealgica de la misma, es decir, para cada Doctor
deberemos saber a qu otros Doctores dirigi sus Tesis.
Simplificaremos el escenario al aadir la siguiente restriccin:
No se contempla la figura del codirector de Tesis, es decir, cada Doctor tiene un
nico director de Tesis que, necesariamente, ser otro Doctor de la Academia.
Para este primer escenario se considerar una clase AcademiaS que implemente la interfaz
AcademiaIF y que permita almacenar y gestionar la informacin de una Academia con rbol
Genealgico Simplificado. Ntese que en este escenario el mtodo addSupervision() descrito
en la interfaz AcademiaIF no tiene efecto alguno.
De igual modo, existir una clase DoctorS que implemente la interfaz DoctorIF y que permita
gestionar la informacin de un Doctor dentro de una Academia. A continuacin se detallan los
atributos y nuevos mtodos que deber tener dicha clase:
publicclassDoctorSimplementsDoctorIF{
privateintid;/*IdentificadorunvocodelDoctor*/
privateAcademiaSacademia;/*AcademiaalaqueperteneceelDoctor*/
/*ConsultaeldirectordeTesisdeldoctor*/
/*@returnselDoctorquefuesudirectordeTesis*/
/*nullencasodequeseaelfundadordelaAcademia*/
publicDoctorSgetSupervisor();
/*Inclyaseaqutodoloquehagafaltaparaunacorrectaimplementacin.*/
...
}

Para ambos atributos se implementarn los getters correspondientes, pero no ser necesario
implementar setters, ya que, como esos datos no se vern modificados tras la creacin del nuevo
Doctor, delegaremos en el constructor de la clase la tarea de instanciarlos al ser creado.
Para ver un ejemplo de este escenario supongamos que los nmeros 17 representan los objetos de
la clase DoctorS y que la informacin sobre la cual se ha construido la Academia es la siguiente:

La Academia fue fundada por 1.

La Tesis de 2 fue dirigida por 1.
La Tesis de 3 fue dirigida por 2.
La Tesis de 4 fue dirigida por 2.
La Tesis de 5 fue dirigida por 4.
La Tesis de 6 fue dirigida por 2.
La Tesis de 7 fue dirigida por 3.

Las siguientes llamadas produciran el resultado indicado:

1.getSupervisor()
6.getSupervisor()
7.getAncestors(2)
7.getAncestors(3)
7.getAncestors(4)
1.getStudents()
2.getStudents()
1.getDescendants(2)
3.getSiblings()

null(eselfundadordelaAcademia)
2
[2,3]
[1,2,3]
[1,2,3](nohaymsgeneraciones)
[2]
[3,4,6]
[2,3,4,6]
[4,6]

Preguntas tericas (trabajo del estudiante).

Las siguientes preguntas son previas al trabajo de implementacin y debern ser respondidas por el
estudiante e incluidas en la memoria de prctica para su evaluacin.
1.1 La clase DoctorS implementa la interfaz DoctorIF que, a su vez, extiende la interfaz
CollectionIF<Doctor>. De los Tipos Abstractos de Datos estudiados en la asignatura,
cules se pueden utilizar para representar las relaciones de direccin de tesis doctorales?
Cmo deberan utilizarse esos TAD?
1.2 Entre los TAD considerados en la pregunta anterior, escoja razonadamente uno y explique
cmo funcionara cada uno de los mtodos detallados en la interfaz DoctorIF y el mtodo
getSupervisor() de la clase DoctorS. Cul sera su coste asinttico temporal en el
caso peor? (Sera un buen ejercicio hacerlo para cada uno de los TAD considerados en 1.1)
1.3 Atenindonos a este escenario, para cada uno de los cuatro mtodos descritos en la interfaz
DoctorIF, pueden aparecer repeticiones? Justifique su respuesta.

2.3 Segundo escenario: Academia con rbol Genealgico

Completo.
En el primer escenario asumimos que una Tesis Doctoral slo puede ser dirigida por un nico
Doctor, pero en la prctica ocurre con frecuencia que haya ms de un director (denominados
codirectores) para una misma Tesis Doctoral.
7

En este segundo escenario eliminaremos esa restriccin. Para lo cual consideraremos una clase
AcademiaC que implementar la interfaz AcademiaIF y que permita almacenar y gestionar la
informacin de una Academia con rbol Genealgico Completo.
Ntese que, cuando se permiten codirectores, un acadmico puede asociarse a ms de una
generacin. En la figura de la pgina 3 se puede ver el caso de Jan Van Mill, que sera Descendiente
Acadmico de Johannes de Groot de segunda generacin por parte de su codirector Pieter Cornelis
Baayen y de tercera generacin por parte de su codirector Eric van Douwen.
Anlogamente, existir una clase DoctorC que implemente la interfaz DoctorIF y que permita
gestionar la informacin de un Doctor dentro de una Academia con rbol Genealgico Completo. A
continuacin se detallan los atributos y nuevos mtodos que deber tener dicha clase:
publicclassDoctorCimplementsDoctorIF{
privateintid;/*Identificadorunvoco*/
privateAcademiaCacademia;/*Academiaalaquepertenece*/
privateCollectionIF<DoctorC>students;/*Aquieneshadirigidolatesis*/
/*ConsultalosdirectoresdeTesisdeldoctor.*/
/*@returnsunalistaconlosDoctoresquefueronsusdirectoresdeTesis.*/
publicCollectionIF<DoctorC>getSupervisors();
/*Inclyaseaqutodoloquehagafaltaparaunacorrectaimplementacin.*/
...
}

Al igual que en el primer escenario, implementaremos los getters correspondientes a todos sus
atributos y delegaremos en el constructor de la clase la tarea de instanciarlos al ser creado un nuevo
objeto.
Veamos un ejemplo que ilustre este escenario. En esta ocasin, los nmeros 17 representan los
objetos de la clase DoctorC y la informacin sobre la cual se ha construido la Academia es la
siguiente:

La Academia fue fundada por 1.

La Tesis de 2 fue dirigida por 1.
La Tesis de 3 fue codirigida por 1 y 2.
La Tesis de 4 fue dirigida por 2.
La Tesis de 5 fue codirigida por 1 y 3.
La Tesis de 6 fue codirigida por 4 y 5.
La Tesis de 7 fue dirigida por 3.

Entonces, las siguientes llamadas produciran el resultado indicado (recuerde que el orden en las
colecciones no es relevante):

1.getSupervisors()
6.getSupervisors()
7.getAncestors(2)
7.getAncestors(3)
1.getStudents()

[](eselfundadordelaAcademia)
[4,5]
[1,2,3]
[1,2,3](nohaymsgeneraciones)
[2,3,5]

2.getStudents()
1.getDescendants(2)
3.getSiblings()

[3,4]
[2,3,4,5,6,7]
[2,4,5]

Preguntas tericas (trabajo del estudiante).

2.1 Explique cmo cambian las relaciones de supervisin en este segundo escenario. A la hora
de representar el problema, puede aplicarse directamente el mismo TAD utilizado en el
primer escenario? Por qu?
2.2 Razone, sin realizar ningn tipo de implementacin, cmo funcionaran en este escenario los
mtodos de la interfaz DoctorIF y el mtodo getSupervisors() de la clase DoctorC
suponiendo que la clase AcademiaC se implemente utilizando una lista de objetos de la
clase DoctorC.
2.3 Basndose en la respuesta a la pregunta anterior, supongamos que se aade a la clase
DoctorC un nuevo atributo supervisors con la coleccin de los doctores que dirigieron
su tesis doctoral (y, en consecuencia, el mtodo getSupervisors() se convierte en un
getter de dicho atributo). Cmo afectara esto al espacio necesario para almacenar el rbol
Genealgico de la Academia en memoria? Y cmo afectara a la programacin y al tiempo
de ejecucin de los mtodos?
2.4 Supongamos que la lista de objetos de la clase DoctorC referida en la pregunta 2.2 se
encuentra siempre ordenada segn el atributo id. Cmo se podra aprovechar en la
implementacin de los mtodos para mejorar el coste temporal de las operaciones de
consulta? Cmo afectara a la operacin de modificacin?
2.5 Supongamos que levantamos la restriccin de que en una Academia slo exista un Doctor
sin supervisores dentro de la Academia y permitimos que haya varios Doctores en esa
situacin. Habra que hacer cambios en la implementacin? Cules y por qu?
2.6 Atenindonos a este escenario, para cada uno de los cuatro mtodos descritos en la interfaz
DoctorIF y para el mtodo getSupervisors() de la clase DoctorC, pueden aparecer
repeticiones? Justifique su respuesta.

3. Implementacin.
Se deber realizar un diseo en Java que contenga las siguientes clases:

Clases AcademiaS y DoctorS que implementarn, respectivamente, las interfaces

AcademiaIF y DoctorIF, permitiendo as gestionar una Academia con rbol Genealgico
Simplificado (ver apartado 2.2).
Clases AcademiaC y DoctorC, que implementarn, respectivamente, las interfaces
AcademiaIF y DoctorIF, permitiendo as gestionar una Academia con rbol Genealgico
Completo (ver apartado 2.3 incluyendo las preguntas 2.2 a 2.6).

Estas cuatro clases debern implementarse en un nico paquete llamado:

es.uned.lsi.eped.pract2016

Para la implementacin de las estructuras de datos se debern utilizar las interfaces

proporcionadas por el Equipo Docente de la asignatura. La implementacin de los mecanismos
de Entrada/Salida y el Estudio Emprico del Coste ser proporcionada por el Equipo Docente a
travs del Curso Virtual.

3.1 Parmetros de entrada.

El programa recibir tres parmetros de entrada que determinarn su comportamiento. El orden y
significado de los parmetros ser el siguiente:
1. Seleccin del escenario que se desea utilizar, que tendr nicamente dos valores vlidos:
S para el escenario 1 (Academia con rbol Genealgico Simplificado).
C para el escenario 2 (Academia con rbol Genealgico Completo).
2. Fichero de datos, que contendr el nombre del fichero de datos con el que se construir la
Academia. Ntese que (debido a la definicin de ambos escenarios) los ficheros de datos
para el escenario 2 no son compatibles con el escenario 1 (pero s a la inversa).
3. Fichero de operaciones, que contendr el nombre del fichero de operaciones que se desean
realizar sobre los datos contenidos en la Academia.

3.2 Estructura del fichero de datos.

El fichero de datos contendr todos los datos necesarios para construir la Academia, es decir, quin
la fund y el histrico de direccin de tesis doctorales. Con respecto a este histrico, cuando se
afirme que A ha dirigido a B se entender que el doctor A ya perteneca a la Academia..
Toda la informacin referente a la direccin de una Tesis se encontrar en una misma lnea. A
continuacin podemos ver un ejemplo de fichero de datos para el primer escenario que se
corresponde con el ejemplo de la seccin 2.2 de este enunciado:
LaAcademiafuefundadapor1
Tesisde2dirigidapor1
Tesisde3dirigidapor2
Tesisde4dirigidapor2
Tesisde5dirigidapor4
Tesisde6dirigidapor2
Tesisde7dirigidapor3

La accin esperada por el programa ser construir la Academia con rbol Genealgico Acadmico
Simplificado (utilizando para ello un objeto de la clase AcademiaS).
Un ejemplo de fichero de datos para el segundo escenario (basado en el ejemplo de la seccin 2.3)
sera el siguiente:
LaAcademiafueFundadapor1
Tesisde2dirigidapor1
Tesisde3codirigidapor1y2
Tesisde4dirigidapor2
Tesisde5codirigidapor1y3
Tesisde6codirigidapor4y5
Tesisde7dirigidapor3

La accin esperada por el programa ser construir la Academia con rbol Genealgico Acadmico
Completo (utilizando para ello un objeto de la clase AcademiaC).

3.3 Estructura del fichero de operaciones.

El fichero de operaciones contendr una operacin por lnea. Existirn cinco tipos de operaciones
de consulta (una por cada mtodo de consulta que existe en la interfaz DoctorIF ms el mtodo
10

getSupervisor() de la clase DoctorC o getSupervisors() de la clase DoctorC), que se

identificarn por los dos primeros caracteres de la lnea:

1. Operacin de consulta de director(es) de tesis. Los dos primeros caracteres de la lnea sern
SU, a continuacin un espacio y luego el identificador del doctor del cual se desea
conocer su(s) director(es) de tesis encerrado entre comillas. Por ejemplo:
SU3

Esta operacin de consulta deber devolver:

Tesisde3dirigidapor2
Tesisde3codirigidapor1y2

(paraelprimerescenario)
(paraelsegundoescenario)

2. Operacin de consulta de ancestros acadmicos. Los dos primeros caracteres de la lnea

sern AN, a continuacin un espacio, el nombre del doctor del cual se desea conocer sus
ancestros acadmicos encerrado entre comillas y el nmero de generaciones a considerar.
Por ejemplo:
AN42

Cuyo resultado, en ambos ejemplos, sera:

Losancestrosde4hasta2generacionesson1y2

3. Operacin de consulta de estudiantes. Los dos primeros caracteres de la lnea sern ST, a
continuacin un espacio y el nombre del doctor del cual se desea conocer aquellos
estudiantes a quienes ha dirigido sus Tesis Doctorales encerrado entre comillas. Por ejemplo:
ST3

Cuyo resultado deber ser:

3hadirigidolaTesisde7
3hadirigidolasTesisde5y7

(paraelprimerescenario)
(paraelsegundoescenario)

4. Operacin de consulta de descendientes acadmicos. Los dos primeros caracteres de la lnea

sern DE, a continuacin un espacio, el nombre del doctor del cual se desea conocer sus
descendientes acadmicos encerrado entre comillas y el nmero de generaciones a
considerar. Por ejemplo:
DE22

Deber devolver, para ambos escenarios, lo siguiente:

Losdescendientesde2hasta2generacionesson3,4,5,6y7

5. Operacin de consulta de hermanos acadmicos. Los dos primeros caracteres de la lnea

sern SI, a continuacin un espacio y el nombre del doctor del cual se desea conocer sus
hermanos acadmicos encerrado entre comillas. Por ejemplo:

11

SI3

Que deber devolver:

Loshermanosde3son4y6
Loshermanosde3son2,4y5

(paraelprimerescenario)
(paraelsegundoescenario)

Hay que recordar que el orden de las coleccions no es relevante, por lo que las respuestas aqu
mostradas han de tomarse como una posible de entre todas las correctas.

3.4 Medicin de tiempos.

Se desea realizar un estudio emprico del coste que emplean para su ejecucin los mtodos de
consulta indicados en la interfaz DoctorIF y los mtodos getSupervisor() y
getSupervisors() de las clases DoctorS y DoctorC respectivamente.
La implementacin de los mtodos necesarios para realizar este estudio ser proporcionada por el
Equipo Docente.

Estudio emprico del coste temporal (trabajo del estudiante)

3.1 Realice un estudio emprico del coste temporal de los mtodos de consulta de la clase
DoctorS en el que se mida cmo vara el coste segn el nmero de doctores que haya en la
Academia. Comprelo con el estudio terico realizado en la pregunta 1.2.
3.2 Realice un estudio emprico del coste temporal de los mtodos de consulta de la clase
DoctorC en el que se mida cmo vara el coste segn el nmero de doctores que haya en la
Academia. Comprelo con el estudio terico realizado en la pregunta 2.4.

3.5 Salida del programa.

La salida del programa se realizar por la salida estndar de Java y consistir en:

La primera lnea indicar cuntos doctores diferentes forman la Academia.

Para cada operacin presente en el fichero de operaciones se indicar el resultado (ver punto
3.3) y, en la lnea siguiente, se indicar su coste.

Si consideramos las consultas utilizadas en el apartado 3.3 de este enunciado, la salida esperada
para el primer escenario (y teniendo en cuenta que el coste indicado es ficticio a modo de ejemplo y
que el orden en las colecciones no es relevante) sera:
DoctoresenlaAcademia:7.
Tesisde3dirigidapor2
Tiempo:6
Losancestrosde4hasta2generacionesson1y2
Tiempo:20
3hadirigidolaTesisde7
Tiempo:10
Losdescendientesde2hasta2generacionesson3,4,5,6y7
Tiempo:25
Loshermanosde3son4y6
Tiempo:11

Por otro lado, la salida esperada para el segundo escenario sera:

12

DoctoresenlaAcademia:7.
Tesisde3codirigidapor1y2
Tiempo:6
Losancestrosde4hasta2generacionesson1y2
Tiempo:20
3hadirigidolasTesisde5,y7
Tiempo:10
Losdescendientesde2hasta2generacionesson3,4,5,6y7
Tiempo:25
Loshermanosde3son2,4y5
Tiempo:11

4. Ejecucin y juegos de prueba.

Para la ejecucin del programa se deber abrir una consola y ejecutar:
javajareped2016.jar<escenario><datos><operaciones>

<escenario>
<datos>
<operaciones>

seleccin del escenario a considerar (S C).

fichero de datos para construir la Academia.
fichero de operaciones con consultas sobre los Doctores.

El Equipo Docente proporcionar, a travs del curso virtual, juegos de prueba consistentes en un
fichero de datos, un fichero de operaciones y una salida esperada para comprobar el correcto
funcionamiento del programa.
Para la realizacin del estudio emprico del coste, los estudiantes podrn crear diferentes ficheros de
datos con un nmero diferente de doctores, de manera que se pueda medir cmo vara el tiempo que
emplean las operaciones segn dicho nmero.

5. Documentacin y plazos de entrega.

La prctica supone un 20% de la calificacin de la asignatura, y es necesario aprobarla (5 puntos)
para superar la asignatura. Adems ser necesario obtener, al menos, un 4 sobre 10 en el examen
presencial para que la calificacin de la prctica sea tenida en cuenta de cara a la calificacin final
de la asignatura.
Los estudiantes debern asistir a una sesin obligatoria de prcticas con su tutor en el Centro
Asociado. Estas sesiones son organizadas por los Centros Asociados teniendo en cuenta sus
recursos y el nmero de estudiantes matriculados, por lo que en cada Centro las fechas sern
diferentes. Los estudiantes debern, por tanto, dirigirse a su tutor para conocer las fechas de
celebracin de estas sesiones.
De igual modo, el plazo y forma de entrega son establecidos por los tutores de forma independiente
en cada Centro Asociado, por lo que debern ser consultados tambin con ellos.
La documentacin que debe entregar cada estudiante consiste en:

Memoria de prctica, en la que se debern responder a las preguntas tericas e incluir el

estudio emprico del coste detallado en este documento.
Implementacin en Java de la prctica, de la cual se deber aportar tanto el cdigo fuente
como el programa compilado.
13