fundamentos de la informática practica curso

FUNDAMENTOS DE LA INFORMÁTICA
PRACTICA CURSO 2012/2013
GESTIÓN DE LA IMPRESIÓN DE
TIRADAS DE CARTELES
Índice de contenido
1 INTRODUCCIÓN ...........................................................................................................................3
2 DESCRIPCIÓN DE LA PRÁCTICA...............................................................................................3
3 ETAPA 1........................................................................................................................................... 4
3.1 ETAPA 1.1:ORIENTACIÓN A OBJETOS...............................................................................4
3.1.1 OBJETIVOS..................................................................................................................... 4
3.1.2 REQUISITOS PREVIOS..................................................................................................4
3.1.3 ENUNCIADO: CREACIÓN DE UNA CLASE TIRADA............................................... 4
3.2 ETAPA 1.2: EJECUCIÓN DE APLICACIONES.....................................................................6
3.2.1 OBJETIVOS..................................................................................................................... 6
3.2.2 REQUISITOS PREVIOS..................................................................................................7
3.2.3 ENUNCIADO: JAVA, BLUEJ Y EL MÉTODO MAIN...................................................7
4 ETAPA 2........................................................................................................................................... 7
4.1 ETAPA 2.1: COMPOSICIÓN...................................................................................................7
4.1.1 OBJETIVOS..................................................................................................................... 7
4.1.2 REQUISITOS PREVIOS..................................................................................................8
4.1.3 ENUNCIADO: CREACIÓN DE CARTELES................................................................ 8
4.2 ETAPA 2.2: ORGANIZANDO LAS TIRADAS.................................................................... 10
4.2.1 OBJETIVOS................................................................................................................... 10
4.2.2 REQUISITOS PREVIOS................................................................................................10
4.2.3 ENUNCIADO: CREACIÓN DEL GESTOR DE TIRADAS.........................................10
5 ETAPA 3......................................................................................................................................... 12
5.1 ETAPA 3.1: HERENCIA Y POLIMORFISMO......................................................................12
5.1.1 OBJETIVOS................................................................................................................... 12
5.1.2 REQUISITOS PREVIOS................................................................................................13
5.1.3 ENUNCIADO: EXTENDIENDO LAS TIRADAS A TIRADAS CON TROQUELADO
...................................................................................................................................................13
5.2 ETAPA 3.2 (OPCIONAL PARA MECÁNICA Y TECNOLOGÍA INDUSTRIAL):.............13
5.2.1 OBJETIVOS................................................................................................................... 13
5.2.2 REQUISITOS PREVIOS................................................................................................14
5.2.3 ENUNCIADO: ORDENANDO LAS TIRADAS...........................................................14
6 FECHAS Y NORMAS DE ENTREGA......................................................................................... 15
6.1 FECHAS................................................................................................................................. 15
6.2 DOCUMENTACIÓN A ENTREGAR....................................................................................15
7 EVALUACIÓN DE LA PRÁCTICA............................................................................................. 16
8 PREGUNTAS AL EQUIPO DOCENTE.......................................................................................16
1 INTRODUCCIÓN
Este documento contiene el enunciado de la práctica de la asignatura de
Fundamentos de la Informática correspondiente al curso 2012/2013. Esta práctica
consistirá en la realización de un programa Java, siguiendo la metodología de
programación orientada a objetos. Para ello, es necesario conocer los conceptos de
'objeto', 'clase', 'métodos', 'atributos' o 'campos', y 'relaciones' entre objetos. El
objetivo de este ejercicio consiste en poner en práctica la capacidad de diseñar e
implementar un sistema en JAVA, partiendo de una especificación de requisitos. La
forma de desarrollarlo será partiendo del enfoque más básico y avanzando de forma
iterativa. Para ello planteamos tres etapas. En cada etapa se partirá del diseño y
desarrollo de la etapa inmediatamente anterior para añadir nuevas características y
funcionalidades.
2 DESCRIPCIÓN DE LA PRÁCTICA
A grandes rasgos, la práctica consiste en el desarrollo de un sistema para la
gestión de una empresa dedicada a la impresión de tiradas de carteles. Para ello, el
sistema deberá llevar un recuento de las tiradas de carteles y gestionar los archivos
de imagen asociados. El sistema debe gestionar qué empresa ha solicitado cada
tirada, bajo qué presupuesto, etc.
En una última etapa, veremos cómo extender el sistema para poder cubrir el
troquel de las imágenes impresas sin necesidad de modificar las clases ya
implementadas haciendo uso de los mecanismos de herencia y polimorfismo.
RECOMENDACIÓN: la práctica se realiza a lo largo del cuatrimestre, y
forma parte del estudio de la asignatura. Para cada etapa se indican
fechas de entrega. Es conveniente hacer una primera lectura
completa de este documento para tener una visión global de lo que
se pide, y organizar apropiadamente el estudio de la asignatura.
3 ETAPA 1
3.1
ETAPA 1.1:ORIENTACIÓN A OBJETOS
3.1.1
OBJETIVOS
En la primera etapa de la práctica se van a afianzar los conceptos básicos de la
programación en Java. Trabajaremos con las características fundamentales de
clase, objeto, atributos y métodos (constructores, métodos que ayudan a la
encapsulación de la clase y métodos de visualización).
Veámoslo con un ejemplo que nos permita comenzar esta primera etapa de la
práctica. En la práctica que queremos resolver este año vamos a necesitar
almacenar información de las tiradas de carteles.
3.1.2
REQUISITOS PREVIOS
Para la realización de esta primera etapa se requiere haber estudiado los temas
4, 5 y 6 del temario detallado de la asignatura, correspondientes a los capítulos 1,
2 y 3, así como los apéndices B, C, D y G del libro de referencia de la Unidad
Didáctica II.
3.1.3
ENUNCIADO: CREACIÓN DE UNA CLASE TIRADA
Se desea diseñar un sistema informático cuyo fin sea permitir a la empresa de
cartelería crear y gestionar la impresión de carteles. Dentro de esta primera parte
se realizará una aproximación básica al modelado inicial de algunos de los
componentes del sistema.
Los componentes básicos de nuestro sistema en este punto del desarrollo
serán las tiradas. Cada tirada es un objeto, por tanto para definir una tirada
necesitaremos crear una clase. Para ello, tenga en cuenta que una tirada tendrá las
siguientes características (campos o atributos):
•
Identificador de tirada, por ejemplo “T3182”
•
Empresa cliente. Un texto, por ejemplo "Orquesta Pepe".
•
Plazo de entrega. Se definirá a través de tres números enteros
correspondientes al día, el mes y el año.
•
Formato, que podrá ser A1, A2, A3 O A4.
•
Si es una imagen en color o en blanco y negro.
•
Número de copias.
•
Si la tirada ha sido ya procesada, es decir, enviada a la imprenta.
Además, un objeto Tirada debe permitir consultar y modificar estos campos a
través de una serie de métodos creados a tal efecto: por cada campo debe haber
dos métodos, uno para consultar su valor y otro para modificarlo, por ejemplo, para
el campo número de copias tendríamos los métodos getNumeroCopias() y
setNumeroCopias().
Esta clase debe tener un método calcularPresupuesto() que calcule
presupuesto a partir del resto de los campos siguiendo la siguiente tabla de precios
(son precios por copia, en Euros):
A1
A2
A3
A4
Color
0,3
0,25
0,20
0,15
Blanco y negro
0,1
0,1
0,05
0,05
Asimismo, debe existir un método, llamado printTirada(), que escriba la
información asociada a la tirada por pantalla (puede hacer uso del método
System.out.println() sobre el cual se puede encontrar información en el capítulo
2.8 del libro de texto), con un formato legible, como por ejemplo muestra la
siguiente ilustración:
Identificador: T82322
Empresa cliente: Orquesta Pepe
Fecha de entrega: 15-01-2013
Presupuesto: 200 euros
Numero de copias: 1000
Formato: A3
Color: SI
Procesada: NO
Ilustración 1: Ejemplo de salida del método printTirada()
RECOMENDACIÓN: Probar con BlueJ creando tiradas, modificando sus
datos, escribiéndolas por pantalla, etc. ¿Cuántas tiradas puedes crear?
¿Cómo puedes acceder a ellas en BlueJ?
3.2
ETAPA 1.2: EJECUCIÓN DE APLICACIONES
3.2.1
OBJETIVOS
Es importante comprender que Java y BlueJ son cosas diferentes. Java es un
lenguaje de programación, mientras que BlueJ es un entorno de programación que
nos permite programar en Java. BlueJ está pensado para el aprendizaje de Java, y
proporciona distintas herramientas que permiten inspeccionar las partes de un
programa, tanto en la parte de diseño (cuando estamos escribiendo el código)
como en la de ejecución (cuando el código se ejecuta, se crean los objetos en
memoria, etc.)
Una de las herramientas de BlueJ que pueden resultar más útiles, pero a la vez
pueden despistar más, es el banco de objetos u object bench (capítulo 1 del libro,
se muestra un ejemplo en la ilustración 2). En conjunto con otras herramientas
como el inspector de objetos, resulta muy interesante para jugar con los objetos en
tiempo de ejecución de forma interactiva. BlueJ nos permite ejecutar nuestras
aplicaciones mediante la invocación de los métodos de sus objetos, pero no es ésta
la única manera de hacerlo.
Ilustración 2: Banco de objetos (recuadrado en verde) en BlueJ
A estas alturas sabemos que cada clase dispone de una serie de métodos y
campos, que son propios de los objetos que creamos a partir de dicha clase, es
decir, que para poderlos utilizar necesitamos crear primero un objeto. Por ejemplo,
la clase Tirada que hemos creado tiene un método para escribir por pantalla su
contenido formateado, que sólo podrá ser invocado una vez tengamos algún objeto
de esta clase. Pues bien, existe otro tipo de métodos que no son propios de los
objetos, sino de las clases. De esta forma, no necesitamos una instancia particular
de la clase (objeto) para invocarlos.
Java, más allá de BlueJ, nos permite ejecutar los programas que creamos de
forma independiente. La ejecución fuera de BlueJ comienza sin que exista ningún
objeto (en BlueJ primero se creaban objetos que se almacenan en el banco de
objetos para posteriormente invocar sus métodos). Antes de tener objetos, lo único
que tenemos son las clases que los definen, por lo que deberemos usar un método
de clase (de los que hablábamos en el párrafo anterior) para poder iniciar la
ejecución.
Un caso particular de estos métodos de clase es el método main(), que es el
que se utiliza como punto de partida para iniciar la ejecución de un programa en
Java (véase el apartado 3.2.2 ).
RECOMENDACIÓN: Al final de este apartado debería entender la
diferencia entre ejecutar un programa en BlueJ y hacerlo de forma
independiente, esto es, por ejemplo, ejecutarlo desde la línea de
comandos (símbolo de sistema en Windows).
3.2.2
REQUISITOS PREVIOS
Además de los expuestos en la sección 3.1.2, debe consultarse el libro de
texto, capítulo 7.15, sobre métodos de clase. En el apéndice E del libro de texto
puede encontrar más información sobre el método main(), en concreto en el
apartado E1. Puede consultar también el capítulo 3.9 (Objetos que crean objetos)
del libro de texto si necesita más información acerca de la creación de objetos
desde el código.
3.2.3
ENUNCIADO: JAVA, BLUEJ Y EL MÉTODO MAIN
Añada un método main(), incluido en una nueva clase llamada Lanzador creada
a tal efecto. Dentro de él pruebe a crear varios instancias de la clase Tirada con
diferentes características y a acceder a las mismas mediante los métodos
pertinentes, escríbala en pantalla, use los métodos apropiados para modificarla y
vuelva a escribirla por pantalla para ver cómo su contenido ha cambiado. Ejecute el
programa desde BlueJ y desde la línea de comandos (consola o símbolo de
sistema, según el sistema operativo que utilice).
IMPORTANTE:
La
presente
práctica
debe
poderse
ejecutar
independientemente de BlueJ de cara a su entrega y corrección.
4 ETAPA 2
4.1
ETAPA 2.1: COMPOSICIÓN
4.1.1
OBJETIVOS
Los objetos pueden contener otros objetos y utilizarlos para realizar distintas
tareas. De esta forma, cuando un objeto contiene otros objetos, hablamos de
Composición. En Java existen además estructuras de datos que nos permiten
agrupar objetos, como es el caso de las listas, los conjuntos o los mapas. De esta
forma si quisiéramos representar una Universidad con estudiantes y profesores,
podríamos, por ejemplo, crear una clase Universidad que tuviera un campo de tipo
lista de objetos de la clase Persona, como se muestra en la ilustración 3.
Tendríamos así que una Universidad se compone de personas.
Ilustración 3: Diagrama de clases correspondiente al ejemplo de la
Universidad (se han omitido los constructores)
Por otra parte, a medida que la aplicación que estamos construyendo se hace
más grande y compleja, conviene ir documentando las clases que hemos creado, no
sólo para que terceras personas puedan comprender su funcionalidad sin tener que
leer minuciosamente el código, sino para que nosotros mismos podamos en el
futuro reutilizarlas de una forma sencilla. Para la generación de documentación en
Java disponemos de la herramienta Javadoc, que por medio de determinado tipo de
comentarios que podemos incluir en nuestro código, permite la generación posterior
de documentación a partir del mismo.
4.1.2
REQUISITOS PREVIOS
Esta etapa requiere haber estudiado los temas 7, 8 y 9 del temario detallado
incluido en la guía de estudio de la asignatura. Encontrará información más
detallada sobre el mecanismo de composición y la generación de documentación en
el libro de texto de la asignatura en los capítulos 4 y 5. Las lectura de las secciones
comprendidas entre la 7.3 y la 7.6 del libro, ambas incluidas, sobre buenas prácticas
en el diseño de aplicaciones es también recomendable.
4.1.3
ENUNCIADO: CREACIÓN DE CARTELES
NOTA IMPORTANTE: leer primero los requisitos completos
antes de tomar decisiones acerca de cómo desarrollar la solución.
La primera aplicación de la composición en nuestro problema es la creación de
una clase Cartel para la gestión de ficheros de imagen. En esta práctica
consideramos que el concepto cartel se refiere a un fichero de imagen con ciertas
características. Debemos crear dicha clase y aplicar composición siguiendo las
siguientes especificaciones:
1. Un objeto de la clase Cartel debe tener asociado:
a) Un identificador de cartel, por ejemplo “C7384”.
b) Un nombre de fichero en donde se encuentra almacenado el cartel. Por
ejemplo "cartel_823j32.jpg"
c) Una ruta de directorio en donde se encuentra el fichero. Por ejemplo
“/home/user/carteles/”
d) Unas dimensiones en píxeles (altura y anchura).
e) Al igual que en la clase Tirada, la clase Cartel debe ofrecer un método que
muestre en pantalla la información asociada al cartel.
2. Composición: Una tirada tiene asociado un cartel. Por tanto, necesitaremos
ahora un nuevo campo en la clase Tirada y los métodos get() y set()
correspondientes que devuelvan o requieran el objeto de la clase Cartel
asociado. Además, el método printTirada() tendrá que actualizarse para que
imprima los datos del cartel correspondiente.
Documente las clases que ha creado hasta ahora. En el apartado 5.10.2 del
libro de texto se detalla la mínima documentación que se debería incluir.
Como siguiente paso, añada al método main() el código necesario para lanzar
la aplicación de forma independiente y que contenga el código necesario para crear
una tirada, crear un cartel y asignarle el cartel a la tirada creada.
4.2
ETAPA 2.2: ORGANIZANDO LAS TIRADAS
4.2.1
OBJETIVOS
Hasta ahora hemos construido una tirada y su cartel asociado. El siguiente
paso es añadir la posibilidad de trabajar con diferentes tiradas independientes. Esto
proporciona un nuevo nivel de organización.
4.2.2
REQUISITOS PREVIOS
Esta etapa se basa en los mismos principios que la etapa 2.1, por lo que los
temas que deben estudiarse son los mismos. Requiere un dominio mayor de los
conceptos que se presentan, con el objetivo de profundizar en el uso del mecanismo
de composición para ampliar la aplicación que estamos desarrollando.
4.2.3
ENUNCIADO: CREACIÓN DEL GESTOR DE TIRADAS
Ahora que sabemos cómo utilizar el mecanismo de composición, podemos
mejorar nuestro sistema para incluir más de una tirada. Para ello, cree una nueva
clase GestorTiradas que incluya una lista de tiradas.
El sistema debe proporcionar las siguientes funcionalidades (métodos):
1. Listar todas las tiradas e imágenes correspondientes, mostrando la
información relativa a cada tirada.
2. Devolver la ruta y acceso de un cartel dado un identificador.
3. Añadir un objeto de tipo Tirada a la lista.
4. Se desea tener la posibilidad de eliminar información en el caso de que los
clientes quieran anular una tirada. El sistema debe permitir eliminar todas las
tiradas correspondientes a una empresa con una determinada fecha de
entrega que aún no hayan sido procesadas.
5. Con el fin de emitir facturas, el sistema debe permitir, dado un nombre de
empresa, listar cada una de las tiradas asociadas, imprimiendo los datos de la
tirada incluyendo el presupuesto, y calcular el presupuesto suma de todas las
tiradas.
6. Con el fin de mantener la coherencia con el sistema de ficheros, la clase
gestora debe permitir modificar la ruta de acceso o nombre de fichero de un
cartel. Para ello, la clase deberá disponer de un método que, dado un
identificador y un nombre de fichero nuevo y ruta de acceso nueva (3
parámetros de entrada), modifique el objeto cartel correspondiente según el
identificador con los nuevos valores nombre de fichero y ruta de acceso.
EJERCICIO: Suponiendo que existan varias tiradas asociadas al
mismo cartel, ¿sería necesario modificar el objeto cartel varias
veces, o sólo una? ¿Por qué?
Se pide además añadir al método main() que se creó en el apartado 4.1 el
código necesario para:
1. Crear un gestor de tiradas.
2. Crear varios carteles.
3. Crear varias tiradas asociadas a diferentes carteles de los creados en el punto
anterior. Algunas de estas tiradas pueden coincidir en la empresa, fecha o
cartel.
4. Añadir las nuevas tiradas al sistema.
5. Listar el presupuesto asociado a una empresa en base a las tiradas anteriores.
6. Modificar la información relativa a uno de los carteles en el sistema de
ficheros.
7. Listar la información de las tiradas para comprobar que se ha actualizado la
información de los carteles.
5 ETAPA 3
5.1
ETAPA 3.1: HERENCIA Y POLIMORFISMO
5.1.1
OBJETIVOS
Supongamos que la empresa de impresión de carteles decide ampliar el abanico
de productos que ofrece. Se dan cuenta de que pueden gestionar igualmente la
impresión de mapas turísticos, con la diferencia respecto a los carteles de que
estos mapas llevan un troquelado (doblado), que puede ir en diferente número de
dobleces. Además, los presupuestos cambian al añadirse el coste del troquelado.
Por desgracia, el informático encargado de la implementación del sistema ya
no está en la empresa, por lo que modificar el código podría resultar complejo y
arriesgado en cuanto a que pueden aparecer errores. Sin embargo, aprovechando
las posibilidades que ofrece Java y el paradigma de orientacion a objetos en general,
se pretende extender el sistema para cubrir la gestión de planos turísticos sin
necesidad de modificar las clases ya implementadas.
Para este tipo de situaciones, los lenguajes orientados a objetos, como Java,
disponen de un mecanismo llamado Herencia. La herencia permite construir una
nueva clase que “herede” las características de una clase existente. Por tanto, esta
clase “heredera” o “hija” tiene toda la funcionalidad de la clase de la que hereda
(clase padre, siguiendo con la analogía), permitiendo además la inclusión de nuevos
métodos y campos para extender dicha funcionalidad. Así la clase resultante será
un extensión de la clase que ya teníamos, que aportará las nuevas funcionalidades
que la clase extendida no tenía.
En nuestro caso tendremos que extender la clase Tirada en una nueva clase
TiradaTroquel con un método y un campo adicionales. De este modo, en la lista de la
clase GestorTirada, aunque esté definida como una lista de referencias a objetos de
la clase Tirada, contendrá en realidad dos posibles clases de objetos, sin necesidad
de haber redefinido la lista. A esta propiedad se la denomina polimorfismo.
En orientación a objetos el polimorfismo aparece en distintos contextos. Como
la propia palabra indica, polimorfismo se refiere a que un elemento concreto puede
tener varias formas. En el caso de las variables, el polimorfismo permite que una
variable pueda contener referencias a objetos de diferentes tipos o clases, ya sea el
tipo declarado o cualquier subtipo de éste. Por ejemplo, en esta práctica, una
variable declarada de la forma:
Tirada t;
puede contener referencias a objetos no sólo de la clase Tirada, sino también
objetos de cualquiera de las clases que hereden de Tirada, que en nuestra jerarquía
serán clases hijas (subclases o subtipos) de Tirada.
Los métodos en Java también pueden ser polimórficos, de tal forma que una
llamada a un método en Java puede invocar diferentes métodos dependiendo, como
en el caso anterior, del contexto. El método invocado dependerá del tipo dinámico
de la variable usada para hacer la invocación. Este es el caso del método que calcula
el presupuesto de la tirada. En la clase Tirada original tenía una implementación,
pero en la clase extendida tendrá otra diferente.
En esta parte de la etapa nos vamos a centrar en extender la funcionalidad de
la aplicación sin necesidad de modificar las clases que habíamos creado
anteriormente.
5.1.2
REQUISITOS PREVIOS
Esta etapa requiere haber estudiado los capítulos del libro base de las etapas
anteriores, así como los temas 10, 11 y 12 del temario detallado de la asignatura,
correspondientes a las Secciones de la 7.3 a la 7.6, y los Capítulos 6, 8 y 9 del libro
base para la Unidad Didáctica II. En concreto la sección 8.7.4 y relacionadas, y el
capítulo 9; particularmente el apartado 9.6 y relacionados, ya que resultarán útiles
en la resolución de esta etapa.
5.1.3
ENUNCIADO: EXTENDIENDO LAS TIRADAS A TIRADAS
CON TROQUELADO
En nuestro sistema hasta ahora sólo tiene cabida un tipo de tirada. Se desea
incluir el nuevo tipo de tirada con troquel, que llamaremos TiradaTroquel. Éstas
tienen todas las características de las tiradas originales, con las siguientes
novedades (no se han de modificar las clases que ya teníamos para incluir estos
nuevos tipos de tiradas en el sistema):
1. Una tirada con troquel se caracteriza por su número de divisiones, que
puede ser dos, tres, cuatro, seis u ocho, indicando el número de partes
en las que queda dividido el papel una vez aplicado el troquel.
2. En el cómputo del presupuesto debe añadirse un 15% del precio por el
troquelado, independientemente del número de divisiones que se
apliquen.
3. Haciendo uso del mecanismo del polimorfismo, la impresión en pantalla
de la información de la tirada debe incluir el número de divisiones.
IMPORTANTE: Para eliminar en la medida de lo posible la
redundancia de código, es crucial reutilizar todos los métodos
posibles de la clase padre. Por ejemplo, no será necesario
implementar de nuevo el calculo del presupuesto en la nueva clase
heredada. Para ello, podemos emplear la palabra reservada “super”.
Se pide además incluir en el método main() que lanza la aplicación, el código
necesario para crear varios carteles y tiradas con y sin troquel, y añadirlos al
sistema.
5.2
ETAPA 3.2 (OPCIONAL PARA MECÁNICA Y TECNOLOGÍA
INDUSTRIAL):
5.2.1
OBJETIVOS
Hasta llegar a esta última etapa hemos hecho un recorrido por los aspectos
más importantes de la programación orientada a objetos en Java. Para finalizar el
diseño e implementación de la aplicación que tenemos entre manos, vamos a
introducir una nueva funcionalidad a la aplicación. Incorporaremos en el sistema la
distinción entre tiradas facturadas o no facturadas. Con el requisito de que se pueda
presentar al usuario las tiradas facturadas de una empresa ordenadas por fecha.
5.2.2
REQUISITOS PREVIOS
Para la realización de esta parte es necesario haber estudiado y tener claro
todo lo que se ha ido proponiendo a lo largo de la presente práctica.
5.2.3
ENUNCIADO: ORDENANDO LAS TIRADAS
El objetivo de este apartado es que se pueda mostrar las tiradas ya facturadas
relativas a una empresa, ordenadas por fecha de entrega, de la tirada más reciente
a la más antigua. Un requisito de este apartado es que sólo ha de modificarse la
clase GestorTiradas, por lo que tendremos que definir una nueva lista de tiradas
facturadas en esta clase. Necesitaremos también un método para, dado un
identificador de tirada, retirar ésta de la lista original e introducirla en la lista de
tiradas facturadas.
Para mostrar las tiradas facturadas de forma ordenada por pantalla tenemos
dos opciones: almacenar las tiradas facturadas con cierto orden, u ordenar las
tiradas en el momento de presentarlas por pantalla. En este último caso, cada vez
que queramos visualizar las tiradas facturadas por pantalla habría que reordenarlas.
Como sólo queremos ordenarlas por fecha de entrega, no necesitamos reordenarlas
cada vez, por lo que elegiremos la primera alternativa que nos permite reordenar
únicamente cuando una nueva tirada sea añadida al gestor. Por tanto, se ha de
modificar el código de inserción de tiradas en la lista de tiradas facturadas, de
forma que éstas se inserten de forma ordenada empezando por la más antigua y
terminando por la más reciente, siempre según su plazo. No es necesario usar
estructuras de datos que proporcionen ordenación; se pide utilizar la misma
estructura de lista que ya teníamos, modificando la manera en que se inserta una
tirada. Ahora en lugar de simplemente añadirla, tendremos que buscar previamente
la posición en la lista donde corresponde insertarla según su fecha de entrega y
entonces insertarla en dicha posición.
Se pide también incluir en el método main() el código necesario para
comprobar el correcto funcionamiento de las modificaciones realizadas con
distintos tipos de tiradas, de forma que se presenten por pantalla listas de tiradas
ordenadas por su fecha de entrega.
6 FECHAS Y NORMAS DE ENTREGA
6.1
FECHAS
La realización de la práctica se llevará a cabo en los Centros Asociados, siendo
las sesiones organizadas y supervisadas por el tutor de la asignatura. Habrá como
mínimo tres sesiones presenciales de obligatoria asistencia. En cada sesión se
abordará cada una de las partes de las que consta la práctica. Los alumnos deberán
ponerse en contacto con su Centro Asociado para informarse acerca de cuándo
tendrán que asistir a las sesiones. Las fechas orientativas para la realización de cada
una de las etapas serán:
•
Finales de Marzo. Realización de la primera parte de la práctica.
•
Finales de Abril. Realización de la segunda parte de la práctica.
•
Mediados de Mayo. Realización de la tercera parte de la práctica.
6.2
DOCUMENTACIÓN A ENTREGAR
La entrega de la práctica tiene que constar de dos partes:
•
Una memoria de no más de 6 hojas donde se explique la especificación y
el diseño realizados en cada parte de la práctica.
•
Para cada parte de la práctica se deben entregar, tanto los ficheros
fuente, como un fchero jar que permita la ejecución de cada una de
estas partes.
•
Los nombres de los ficheros y carpetas que compongan la práctica
entregada deben contener sólo caracteres correspondientes a las letras
de la A a la Z, tanto mayúsculas como minúsculas, números del 0 al 9 y
los caracteres especiales '-' y '_'. No deben utlizarse otros caracteres
tales como tildes o símbolos.
7 EVALUACIÓN DE LA PRÁCTICA
Los tutores de la asignatura deberán mandar un informe (*) y una calificación
orientativa de cada alumno antes del día 18 de mayo. Además, deberán enviar
mediante correo electrónico a la dirección enrique@lsi.uned.es un fichero
comprimido con los códigos de todas las prácticas de los alumnos de su centro
asociado, de modo que el equipo docente pueda revisarlas (**).
(*) Los informes se mandarán al equipo docente a través de una herramienta
Web que estará disponible a partir de Mayo.
(**) Para preparar dicho fichero deben seguir las pautas que aparecen en el
documento Orientaciones del tutor, que podrán encontrar en el foro de los tutores
de la asignatura.
NOTA IMPORTANTE: Los tutores tienen que cumplir una serie de requisitos
ante los alumnos debido a que la práctica cuenta para la calificación de la
asignatura. Por tanto antes de entregar las calificaciones al equipo docente
deberán:
•
Publicar la nota de las prácticas en un lugar accesible para los alumnos
(ya sea vía web o mandar un fax al centro asociado).
•
Establecer un día de revisión de prácticas (previo al periodo de entrega
de las calificaciones al equipo docente), dado que éstas forman parte de
la evaluación del alumno.
Es importante que se mantengan todos los identificadores definidos en el
enunciado, es decir, el nombre de las clases, atributos y métodos debe ser tal y
como se define en este enunciado.
Las prácticas tienen carácter INDIVIDUAL. Para evitar posibles copias todas
las prácticas pasarán por un sofware detector de copias. La detección de prácticas
copiadas implicará un SUSPENSO en TODO el curso, es decir, convocatorias de Junio
y Septiembre, para todos los implicados.
Los alumnos que quieran realizar el examen previamente tenen que haberse
presentado a las prácticas y tener un aprobado en éstas. El informe del tutor se
considera a efectos de subir nota.
Las prácticas no se guardan de un curso para otro.
8 PREGUNTAS AL EQUIPO DOCENTE
El equipo docente atenderá preguntas de carácter metodológico y de diseño.
Las preguntas relativas a la instalación del entorno de desarrollo, puesta en
funcionamiento y errores de compilación deben ser remitixdas a los tutores de los
centros asociados.
Felisa Verdejo Maillo, Catedrática: Jueves de 16:00 a 20:00 ; Teléfono:
91.398.64.84 Mail: felisa@lsi.uned.es
Enrique Amigó Cabrera, Profesor Contratado Doctor: Jueves de 16:00 a
20:00 ; Teléfono: 91.398.86.51 Mail: enrique@lsi.uned.es
Víctor Fresno Fernández, Profesor Contratado Doctor : Jueves de 16:00 a
20:00 ; Teléfono: 91.398.82.17 Mail: vfresno@lsi.uned.es
Roberto Centeno Sánchez, Profesor Ayudante Jueves de 16:00 a 20:00 ;
Teléfono: 91.398.96.96 Mail: rcenteno@lsi.uned.es