Universidad Nacional de Educación a Distancia

Departamento de Lenguajes y Sistemas Informáticos

F UNDAMENTOS DE I NFORM ÁTICA

Práctica Obligatoria
Curso 2018/2019
 Índice general

1. Introducción 2
1.1. Descripción general de la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Etapa 1 4
2.1. ETAPA 1.1 Orientación a Objetos: La clase Abono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3. Enunciado: Implementación de la clase Abono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Familiarización con el entorno BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ETAPA 1.2 Ejecución de Aplicaciones: La clase Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Enunciado: Creación de una clase Lanzador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. ETAPA 2 7
3.1. ETAPA 2.1: Uso de la composición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Enunciado: Creación de la clase Gestor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. ETAPA 2.2: Validando abonos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. ETAPA 3 11
4.1. ETAPA 3.1: Uso de la herencia y polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Enunciado: Añadiendo abonos de tipo anual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. ETAPA 3.2: Extendiendo la funcionalidad del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5. Fechas y normas de entrega 14

5.1. Fechas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Normas de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Evaluación de la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Preguntas al equipo docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6. Apéndices 16

1
 Introducción

La práctica se realizará utilizando Java como lenguaje de programación orientado a objetos. El primer concepto que se
debe conocer es el de objeto, el ladrillo con el que se construye un progama bajo este paradigma de programación. Los objetos
tienen vida cuando nuestro programa está en ejecución, y pueden relacionarse entre si de diversas maneras, proporcionando
al programador las funcionalidades necesarias para resolver una amplia gama de problemas.
La definición de un objeto viene dada por lo que se conoce como clase, siendo ésta la entidad que en realidad diseñaremos
y programaremos, en términos de sus campos o atributos y métodos. Estos campos y métodos nos permiten definir las
caracterı́sticas y funcionalidades de la clase. Una vez definida, a partir de la clase podremos crear objetos, que son los que en
realidad llevarán a cabo la funcionalidad de nuestro programa en tiempo de ejecución.
Por tanto, podemos ver los objetos como los componentes que nos servirán para diseñar nuestro programa, y las clases como
las definiciones de dichos objetos. Una misma clase puede por tanto dar lugar a muchos objetos diferentes, cada uno con
caracterı́sticas diferentes que vendrán dadas por los valores de sus campos.

1.1. Descripción general de la práctica

El objetivo principal de esta práctica es que el alumno sea capaz de crear un sistema informático simplificado para viajar
en tren de cercanı́as. Básicamente, los usuarios pueden abonarse de forma mensual o anual a una determinada zona tarifaria
que cubre ciertas estaciones de tren. Es decir, una vez que el usuario recarga el abono de tren, puede viajar libremente por
las estaciones que cubra la zona tarifaria durante un mes o un año dependiendo del tipo de abono. En lı́neas generales, las
funcionalidades a cubrir por el sistema son:
Alta de abonos: El sistema debe permitir dar de alta un abono con la información correspondiente. Ésta incluye nombre
y apellidos del titular, edad, area (zona tarifaria) que cubre el abono, etc.
Recarga de abonos: El precio de los abonos depende de varios factores, como la zona tarifaria, la edad del usuario o si
el usuario tiene familia numerosa. El sistema debe de ser capaz de calcular el precio de la recarga según estas variables,
además de recargar el abono actualizando por tanto su fecha de caducidad.
Validación de abono: En cada estación hay una máquina por la que los pasajeros tienen que pasar validando su abono.
Tanto si el usuario sale como si entra en una estación, el sistema debe comprobar que el abono se corresponde con la
zona tarifaria en donde se encuentra la estación y también que el abono esté recargado, es decir, que no haya pasado ya
su fecha de caducidad.
Información sobre zonas. Para que el usuario sepa de antemano si puede viajar de una localidad a otra con su abono,
el sistema debe indicar la zona a la que el usuario debe de estar abonado para viajar entre dos localidades concretas.
Tengase en cuenta que las zonas se incluyen unas a otras. Es decir, la zona tarifaria A1 cubre el centro de la capital,
mientras que otras zonas tarifarias (A2,B1, etc) cubren un radio más amplio.
Para la realización de la práctica seguiremos un enfoque iterativo, de forma que el desarrollo se dividirá en etapas. En cada
etapa partiremos del diseño y desarrollo de la etapa inmediatamente anterior, añadiéndole nuevas funcionalidades, poniendo
en juego los conceptos del temario que se van estudiando progresivamente.
RECOMENDACIÓN: la práctica se realiza a lo largo del cuatrimestre y forma parte del estudio de la asignatura.
Para cada etapa el tutor indicará las correspondientes 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.

2
 Descripción general de la práctica

Para facilitar la realización de la práctica, dar un criterio de autoevaluación y homogeneizar la corrección por parte de
los tutores, en cada fase se indicará un conjunto de llamadas (creación de objetos y llamadas a métodos) a los que el sistema
deberá responder, ası́ como la salida esperada. Es importante tener en cuenta que la implementación debe ajustarse a la
definición de objetos y métodos (tipo y número de atributos) invocados en los ejemplos, de forma que los tutores puedan
evaluar todas las prácticas mediante el mismo lote de llamadas.
Por otro lado, cuando afrontamos el desarrollo de una aplicación informática es indispensable y necesario realizar una fase
previa donde se analicen los requisitos y se diseñen las clases necesarias para llevar a cabo las funcionalidades requeridas,
ası́ como la relación entre las mismas. Para ello, antes de comenzar a implementar cada una de las etapas en las que ha sido
dividida la práctica, se debe realizar una lectura completa de la etapa a abordar, realizando un diagrama de clases donde se
representen las clases necesarias, con sus atributos y métodos, y las relaciones entre las clases, para posteriormente comenzar
la fase de implementación de las mismas. El diagrama de clases obtenido en la última etapa debe ser entregado junto al
código de la práctica.

3
 Etapa 1

2.1. ETAPA 1.1 Orientación a Objetos: La clase Abono

2.1.1. Objetivos
En esta primera etapa de la práctica se van a afianzar los conceptos básicos de la programación orientada a objetos: clase,
objeto, atributos y métodos (constructores, métodos que ayudan a la encapsulación de la clase y métodos de visualización).
Además, se hará uso de tipos enumerados para definir el conjunto de valores que puede tomar un atributo.
Veámoslo con un ejemplo que nos permita comenzar esta primera etapa de la práctica. Como ya hemos mencionado, en
la práctica de este año vamos a modelar abonos de tren, que podrán darse de alta, recargarse, y validarse en una estación.
Por tanto, una entidad básica en este dominio es el abono. Para ello, vamos a empezar diseñando e implementando una
clase denominada Abono, que nos permitirá encapsular la información asociada a un abono de cada usuario concreto. De esta
manera, cada abono de tren dado de alta en el sistema será modelado mediante un objeto de dicha clase, con sus caracterı́sticas
comunes (atributos), cuyos valores podrán ser diferentes, representando ası́ a cada uno de los usuarios.
La reutilización de código es un aspecto fundamental de la programación orientada a objetos. Con el fin de poner en práctica
esto, en esta fase se hará uso de la clase Calendar del paquete java.Util. En el apéndice de este documento aparece un ejemplo
de uso de la librerı́a Calendar, donde se captura la fecha actual y se le añaden 30 dı́as. Para más detalles, puede consultarse
https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html

2.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 A, B, C, D y F del libro de referencia de la
Unidad Didáctica II.

2.1.3. Enunciado: Implementación de la clase Abono

En esta primera etapa realizaremos el modelado inicial de alguno de los componentes principales del sistema. Uno de
estos elementos es el abono, que será modelado como una clase a partir de la cual se podrán crear instancias u objetos de la
misma. Cada abono se describe por la siguiente información, que modelaremos como atributos de la clase Abono:

Nombre del titular, que representa el nombre del usuario.

Apellidos del titular, representando los apellidos del mismo.

DNI, representando el número y letra del documento nacional de identidad del usuario.

Año de nacimiento, atributo que indica el año de nacimiento, necesario para estimar el precio de un abono.

Familia numerosa, indicando si el usuario dispone o no del carnet de familia numerosa con vistas a los descuentos
en el precio del abono.

Zona tarifaria, indicando la zona tarifaria a la que está adscrito el abono. Asumiremos que existe un conjunto
predefinido de zonas tarifarias: {A1, A2, B1, B2,C}. Dado que asumimos que existe un conjunto predefinido de zonas,
éstas deberán implementarse como un tipo enumerado.

4
 ETAPA 1.1 Orientación a Objetos: La clase Abono

Fecha de caducidad. Para ello usaremos la clase Calendar del paquete java.Util (Ver apéndice del documento o
https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html)

Además, todo objeto de la clase Abono debe permitir consultar y modificar todos estos campos a través de una serie de
métodos creados a tal efecto: por cada atributo debe haber dos métodos, uno para consultar su valor y otro para modificarlo.
Por ejemplo, para el campo nombre tendremos los métodos getNombre() y setNombre() para consultar su valor y modi-
ficarlo, respectivamente. Finalmente, la clase Abono dispondrá de un método que imprima en pantalla toda su información,
incluyendo DNI, nombre, apellidos, fecha de caducidad, zona tarifaria, fecha de nacimiento y si el abonado tiene familia
numerosa.

RECOMENDACIÓN: jugar con BlueJ creando objetos de la clase Abono, modificando el valor de sus atributos,
mostrándolos por pantalla, etc.

2.1.4. Familiarización con el entorno BlueJ

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 es el banco de objetos u object bench (capı́tulo 1 del libro),
que 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. Podemos ver un ejemplo de los mismos en la figura 2.1, donde se muestran varios
objetos de una clase Pelı́cula en el banco de objetos; y uno de ellos está siendo inspeccionado, lo que nos permite visualizar
los valores de sus atributos.

Figura 2.1: BlueJ con varias pelı́culas creadas en el banco de objetos

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. Java, más allá de BlueJ, nos permite ejecutar los programas que creamos de forma independiente. 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 Abono
que deberemos crear en esta práctica, tendrá métodos para consultar datos como el nombre del abonado o la zona tarifaria,
que sólo podrán ser invocados una vez tengamos creado 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 para
invocarlos. 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

5
Fundamentos de Informática. Práctica Obligatoria. Etapa 1

las clases que los definen, por lo que deberemos usar un método de clase para poder iniciar la ejecución de nuestro programa.
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 2.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/Linux/MacOS).

2.2. ETAPA 1.2 Ejecución de Aplicaciones: La clase Principal

2.2.1. Objetivos
El objetivo de esta etapa es familiarizarse con el concepto de clase principal, implementando para ello un código sencillo
que permita instanciar y acceder a objetos desde un método Main.

2.2.2. Requisitos previos

Además de los expuestos en la sección anterior, debe consultarse el libro de texto la secciónEl método principal). Además,
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.10 “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.

2.2.3. Enunciado: Creación de una clase Lanzador

Para ejecutar nuestro programa de manera independiente de BlueJ y crear el flujo principal del sistema, crearemos una
clase llamada Lanzador, donde implementaremos el método main(). Esta clase contendrá el código en el que se crean
las instancias de objetos necesarias y las llamadas para poder comprobar el funcionamiento del sistema. El tratamiento del
atributo código tiene que ver con la gestión de los abonos y lo trataremos en la siguiente etapa.
El ejercicio a realizar consiste en crear dicha clase Lanzador con un método main(), e implementar en este método el
siguiente código:
Abono a=new Abono();
Zona z=Zona.A1;
a.setZona(z);
a.setNombre("Federico");
a.setApellidos(‘‘Garcı́a López’’);
a.setDNI(‘‘43815923F’’);
a.setFamiliaNumerosa(false);
a.setAnyoNacimiento(1974);
a.imprimeInformacion();
Este código deberı́a crear una instancia del objeto Abono, incluir su información y posteriormente imprimirla. Recomendamos
jugar con más objetos y valores de atributos.

NOTA IMPORTANTE: La presente práctica debe poderse ejecutar independientemente de BlueJ de cara a su
entrega y corrección.

6
 ETAPA 2

3.1. ETAPA 2.1: Uso de la composición

3.1.1. Objetivos
Una manera muy usual de relacionarse los objetos en la programación orientada a objetos es mediante la composición.
Esta relación se produce cuando un objeto contiene a otros objetos para realizar alguna tarea con ellos. En Java tenemos
distintas estructuras de datos para almacenar objetos, permitiéndonos realizar estas relaciones de composición. Algunos
ejemplos son: las listas, los conjuntos o los mapas.
De este modo, en esta etapa haremos uso de la composición para representar la relación que existe entre la clase que gestiona
los abonos y cada uno de los abonos dados de alta en el sistema. Básicamente, como se indica en el libro base de esta
asignatura, una relación de composición consiste en definir como atributo o campo una instancia de otra clase. Por ejemplo,
en nuestro escenario, habrá una clase Gestor que tendrá entre sus atributos una lista de objetos de la clase Abono.
En esta etapa deberá ponerse en práctica los principios de encapsulación de la programación orientada a objetos tal y como se
describe en el libro base de la asignatura. Esto implica que los atributos de las clases deben de estar definidos como privados,
siendo los métodos de la propia clase los únicos que tienen acceso a dichos atributos.
Finalmente, es una buena práctica de programación documentar todo el código que se va realizando, no sólo con el objetivo
de que terceras personas puedan comprender nuestro programa, sino también para que nosotros mismos podamos entender
nuestro código de cara a futuras extensiones, mejoras o modificaciones. Para la generación de documentación, Java nos ofrece
la herramienta Javadoc, que por medio de determinado tipo de comentarios añadidos en nuestro código fuente, nos permite
la generación posterior de toda la documentación de las distintas clases.

3.1.2. Requisitos previos

Para la realización de esta etapa se deben estudiar los temas 7, 8 y 9 del temario detallado 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.

3.1.3. Enunciado: Creación de la clase Gestor

RECOMENDACIÓN: Lea primero los requisitos completos antes de tomar decisiones acerca de cómo desarrollar la
solución.

Nuestra aplicación va a gestionar un conjunto de abonos transporte, que hemos modelado como una clase. Estos abonos se
gestionarán por medio de una clase Gestor. Los sucesos que queremos modelar mediante esta clase son los siguientes:

1. Se da de alta un nuevo abono en el sistema, con toda la información correspondiente.

2. Dada las caracterı́sticas del abono, el sistema devuelve el precio de la recarga.

3. Se indica al sistema que recargue un determinado abono, actualizándose la fecha de caducidad.

Para poder modelar este problema, la clase Gestor tendrá las siguientes caracterı́sticas:

1. La clase contiene una lista de abonos, es decir, todos aquellos abonos que han sido dados de alta en el sistema.

7
Fundamentos de Informática. Práctica Obligatoria. ETAPA 2

2. La clase gestor dispone de un método que permite dar de alta un nuevo abono, es decir, añadir al sistema un objeto
de la clase abono. La fecha inicial de caducidad será anterior a la fecha actual, de forma que hasta que el abono no
sea recargado, el usuario no podrá hacer uso de éste. Tras dar de alta un nuevo abono, el sistema deberá imprimir en
pantalla los datos del abono dado de alta. En nuestro escenario, un mismo usuario no puede tener más de un abono. Por
tanto, el sistema deberá comprobar que no haya ya dado de alta un abono con el mismo DNI. Si lo hay, se imprimirá
en pantalla un mensaje indicándolo.
3. Mediante otro método, la clase gestora deberá imprimir en pantalla el precio de recarga de un determinado abono dado
el DNI del usuario. Si no existe en el sistema ningún abono asociado a ese DNI, se imprimirá en pantalla un mensaje
indicándolo. Para el cálculo de la tarifa, el sistema tendrá de una tarifa base que podrá actualizarse o consultarse.
La tarifa de un abono se calculará de la siguiente forma: El precio de las zonas tarifarias A1,A2,B1,B2 y C será un
100 %,125 %, 150 %, 200 % y 300 % de la tarifa base respectivamente. Además, en caso de que el usuario tenga familia
numerosa o tenga menos de 18 años, ésta se reduce en un 50 %.
4. Dado un DNI asociado a un abono, la clase gestora permitirá recargar un abono, es decir, actualizar la fecha de
caducidad a un mes después de la fecha actual. En caso de que no exista un abono con dicho DNI, el sistema lo
notificará imprimiendo en pantalla un mensaje. En caso de que aun no haya vencido el abono, la fecha se actualizará
igualmente a un mes después de la fecha actual. Finalmente, el sistema imprimirá en pantalla un mensaje indicando
que el abono ha sido recargado y la nueva fecha de caducidad.
NOTA IMPORTANTE: En esta fase es crucial tener en cuenta el concepto de encapsulación. La clase gestora se encarga
de mantener la lista de abonos existentes y la tarifa base. Sin embargo, adelantamos que en fases posteriores surgiran otros
tipos de abonos con otras caracterı́sticas. Los elementos comunes a cualquier tipo de abono que pueda surgir en el futuro
es que tendrán un precio de recarga dependiente de la tarifa base y una fecha de caducidad, pudiendo variar los criterios
de cálculo del precio, la información empleada para ese cálculo, el tiempo de caducidad o la impresión en pantalla de la
información asociada al abono. En términos de programación orientada a objetos, esto implica que el cálculo del precio debe
encapsularse en la propia clase Abono añadiendo en esta clase los métodos que sean necesarios.
En esta etapa se deben documentar todas las clases creadas hasta ahora. En capı́tulo 6, concretamente en la sección 6.11 se
describe los pasos a seguir para documentar las clases correctamente.
Por último, vamos a modificar ahora el método main() de la clase Lanzador para dar de alta y recargar abonos. El sistema
deberı́a ser capaz de responder al siguiente código implementado en la clase Lanzador:
Gestor g=new Gestor();
g.actualizaTarifaBase(10);
Abono a=new Abono();
Zona z=Zona.A1;
Date d=new Date(118,5,2,0,0,0);
a.setNombre(‘‘Federico’’);
a.setApellidos(‘‘Garcia Lopez’’);
a.setDNI(‘‘43815923F’’);
a.setFamiliaNumerosa(true);
a.setAnyoNacimiento(1974);
a.setFechaCaducidad(d);
a.setZona(z);
g.anyadirAbono(a);
g.imprimeImporte(‘‘43815923’’);
g.imprimeImporte(‘‘54353543L’’);
g.recargarAbono(‘‘43815923F’’);

Al ejecutar el main con este código, el sistema deberá:

1. Indicar que ha sido dado de alta un abono e imprimir en pantalla la información relativa a dicho abono.
2. Imprimir en pantalla el importe del abono, que será en este caso el precio de la tarifa base con un descuento del 50 %
por familia numerosa.
3. Imprimir en pantalla un mensaje indicando que el abono asociado al DNI ”54353543L”no existe en el sistema.
4. Imprimir en pantalla un mensaje indicando que el abono asociado al DNI ”43815923F”ha sido recargado y su nueva
fecha de caducidad.
Es importante probar el sistema ante otras situaciones, como diferentes datos del usuario, zona tarifaria, tarifas base, etc.

8
 ETAPA 2.2: Validando abonos

3.2. ETAPA 2.2: Validando abonos

3.2.1. Objetivos
El objetivo de esta etapa es la implementación de los métodos necesarios para validar un abono en una estación de tren
en el momento en el que el usuario entra o sale de la estación.

3.2.2. Requisitos previos

Para la realización de esta etapa es necesario dominar los conceptos de objeto, clase y composición estudiados hasta este
punto.

3.2.3. Enunciado
En esta etapa vamos a ampliar el sistema para que en cada estación se valide el abono del usuario en el momento que
accede o sale de una estación. Para ello, el sistema deberá gestionar un conjunto de estaciones de tren, pudiendo añadir nuevas
estaciones al sistema, de la misma forma que el sistema gestiona el conjunto de abonos dados de alta. Una estación lleva por
nombre la localidad o distrito donde se encuentra y le corresponde una zona tarifaria. Para satisfacer los requisitos del sistema,
la clase Estación deberá disponer de un método que valide un abono, imprimiendo en pantalla si el abono es válido o no.
Esta respuesta dependerá de dos factores: si el abono está dado de alta y recargado, y también si la zona que cubre el abono
incluye la zona tarifaria de la estación. Es importante tener en cuenta que las zonas tarifarias se incluyen unas dentro de otras.
Por ejemplo, un abono asociado a la zona B2 permite viajar por cualquier estación de las zonas A1, A2, B1 o B2. Como
detalle de implementación, para abordar esto se puede hacer uso del método ordinal del tipo enumerado que devuelve un
entero con la posición del valor dentro del enumerado. Por ejemplo Zona.A2.ordinal() devolverı́a el valor 1.
Como prueba, debe implementar en la clase Lanzador las siguientes llamadas y comprobar su correcto funcionamiento:
Gestor g=new Gestor();
g.actualizaTarifaBase(10);
Abono a=new Abono();
Zona z=Zona.A2;
a.setZona(z);
a.setNombre(‘‘Federico’’);
a.setApellidos(‘‘Garcı́a López’’);
a.setDNI(‘‘43815923F’’);
a.setFamiliaNumerosa(false);
a.setAnyoNacimiento(1974);
g.anyadirAbono(a);
g.recargarAbono(‘‘43815923F’’);
Estacion e1=new Estacion();
Estacion e2=new Estacion();
e1.setLocalidad(‘‘Madrid-Atocha’’);
e1.setZona(Zona.A1);
e2.setLocalidad(‘‘San Rafael’’);
e2.setZona(Zona.B2);
g.anyadirEstacion(e1);
g.anyadirEstacion(e2);
e1.validarAbono(a);
e2.validarAbono(a);

Al ejecutar el main con este código, el sistema deberá:

1. Indicar que ha sido dado de alta un abono e imprimir en pantalla la información relativa a dicho abono.

2. Imprimir en pantalla un mensaje indicando que el abono asociado al DNI ”43815923F”ha sido recargado y su nueva
fecha de caducidad.

3. Imprimir en pantalla un mensaje indicando cada una de las estaciones que se han añadido al sistema.

4. Imprimir en pantalla un mensaje indicando que el abono con DNI 43815923F es válido para la estación Madrid-Atocha.

9
Fundamentos de Informática. Práctica Obligatoria. ETAPA 2

5. Imprimir en pantalla un mensaje indicando que el abono con DNI 43815923F NO es válido para la estación de San
Rafael.
De nuevo, es importante hacer más pruebas con diferentes objetos y atributos.

10
 ETAPA 3

4.1. ETAPA 3.1: Uso de la herencia y polimorfismo

4.1.1. Objetivos
En esta parte de la práctica vamos a extender el sistema para que nos permita gestionar distintos tipos de abonos de tren.
En concreto queremos añadir un nuevo tipo de abono anual, que incluirá nuevos atributos y variaciones en los métodos. Para
este tipo de situaciones, los lenguajes basados en la programación orientada 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á una extensión de la clase que ya tenı́amos, que aportará las nuevas funcionalidades que la clase extendida no
tenı́a.
Por otro lado, una vez que el sistema pasa a gestionar tanto abonos, anuales como mensuales, las clase que gestiona los
abonos del sistema no necesita saber si cada uno de los abonos es anual o mensual, dado que los métodos a los que tendrá
que llamar serán los mismos: calcular precio, recargar, etc. Con todo esto, además de la herencia, estamos haciendo uso de un
mecanismo llamado polimorfismo para que el sistema siga funcionando sin tener que modificar el código que ya tenı́amos.
Es decir, todas las llamdas a métodos de objetos Abono seguirán siendo las mismas. De este modo, estudiaremos el uso y
posibilidades que nos ofrecen este tipo de mecanismos de la programación orientada a objetos.

4.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 los Capı́tulos 10 y 11, secciones 12.3 y 12.4 y el capı́tulo 14 y 7 del
libro base para la Unidad Didáctica II.

4.1.3. Enunciado: Añadiendo abonos de tipo anual.

A diferencia del abono que hemos modelado (mensual), la recarga del abono anual actualiza la fecha de vencimiento en
un año despues de la fecha actual. El precio de este abono se calculará de la siguiente forma: tari f a base × n con descuento
del 50 % para familia numerosas pero no para menores de 18 años, donde n es 10, 12, 15, 20 y 30 respectivamente para las
zonas A1, A2, B1, B2 y C. Además, el gobierno ha prometido ciertas ventajas a aquellos que cumplan más de diez años de
recargas anuales, por lo que habrá de añadirse un atributo numeroDeRecargas para mantener dicha información, y actualizarla
con cada recarga. En esta fase diseñe e implemente las clases necesarias para cubrir estas especificaciones.
Como prueba, debe implementar en la clase Lanzador las siguientes llamadas y comprobar su correcto funcionamiento:
Gestor g=new Gestor();
g.actualizaTarifaBase(10);
Abono a1=new Abono();
Zona z1=Zona.A2;
a1.setZona(z1);
a1.setNombre(‘‘Luis’’);
a1.setApellidos(‘‘López López’’);
a1.setDNI(‘‘42523435A’’);
a1.setFamiliaNumerosa(false);

11
Fundamentos de Informática. Práctica Obligatoria. ETAPA 3

a1.setAñoNacimiento(2010);
g.añadirAbono(a1);
g.imprimeImporte(‘‘42523435A’’);
g.recargarAbono(‘‘42523435A’’);
Abono a2=new AbonoAnual();
Zona z2=Zona.B2;
a2.setZona(z2);
a2.setNombre(‘‘Pepe’’);
a2.setApellidos(‘‘Garcı́a González’’);
a2.setDNI(‘‘5283843G’’);
a2.setFamiliaNumerosa(false);
a2.setAñoNacimiento(2004);
g.añadirAbono(a2);
g.imprimeImporte(‘‘5283843G’’);
g.recargarAbono(‘‘5283843G’’);
Estacion e1=new Estacion();
Estacion e2=new Estacion();
e1.setLocalidad(‘‘Madrid-Atocha’’);
e1.setZona(Zona.A1);
e2.setLocalidad(‘‘San Rafael’’);
e2.setZona(Zona.B2);
g.añadirEstacion(e1);
g.añadirEstacion(e2);
e1.validarAbono(a1);
e2.validarAbono(a1);
e1.validarAbono(a2);
e2.validarAbono(a2);

Al ejecutar el main con este código, el sistema deberá:

1. Imprimir en pantalla un mensaje indicando que ha sido dado de alta un abono mensual e imprimir en pantalla la
información relativa a dicho abono.
2. Imprimir el importe 6,25.
3. Imprimir en pantalla un mensaje indicando que ha sido recargado dicho abono, con fecha a un mes después de la actual.
4. Imprimir en pantalla un mensaje indicando que ha sido dado de alta un abono anual e imprimir en pantalla la informa-
ción relativa a dicho abono.
5. Imprimir el importe 200.
6. Imprimir en pantalla un mensaje indicando que ha sido recargado dicho abono, con fecha a un año despues de la actual.
7. Imprimir en pantalla un mensaje indicando que el abono “42523435A” es válido para la estación ”Madrid-Atocha”
8. Imprimir en pantalla un mensaje indicando que el abono “42523435A” NO es válido para la estación ”San Rafael”.
9. Imprimir en pantalla un mensaje indicando que el abono “5283843G” es válido para la estación ”Madrid-Atocha”
10. Imprimir en pantalla un mensaje indicando que el abono “5283843G” es válido para la estación ”San Rafael”.

4.2. ETAPA 3.2: Extendiendo la funcionalidad del sistema

4.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
nuevas funcionalidades en la aplicación.
Ası́ pues, esta última etapa se centrará en extender la funcionalidad de la aplicación, ofreciendo información sobre la zona
tarifaria a la que hay que abonarse para cubrir una estación de origen y una estación de destino.

12
 ETAPA 3.2: Extendiendo la funcionalidad del sistema

4.2.2. Requisitos previos

Para llevar a cabo esta etapa es necesario haber estudiado y dominar todos los conceptos estudiados hasta este punto.

4.2.3. Enunciado
Para abordar esta etapa tendremos que incluir un método en la clase gestor que, dado dos nombres de estación, devuelva
la zona mı́nima a la que tiene que estar abonado el usuario. Algunas consideraciones respecto a este método son:
El método debe tomar como parámetros de entrada dos nombres de estación (localidad o distrito).
En caso de una de las dos estaciones no exista en el sistema, se imprime un mensaje indicándolo.

En caso de que si existan, el método debe imprimir en pantalla la zona más amplia de las dos. Por ejemplo, si las dos
estaciones se encuentran en las zonas A2 y C respectivamente, el método deberı́a imprimir la zona C.
Recordamos que para este método se puede hacer uso de los métodos toString y ordinal del tipo enumerado en Java.
Como prueba, debe implementar en la clase Lanzador las siguientes llamadas y comprobar su correcto funcionamiento:

Gestor g=new Gestor();

Estacion e1=new Estacion();
Estacion e2=new Estacion();
e1.setLocalidad(‘‘Madrid-Atocha’’);
e1.setZona(Zona.A1);
e2.setLocalidad(‘‘San Rafael’’)‘;
e2.setZona(Zona.B2);
g.anyadirEstacion(e1);
g.anyadirEstacion(e2);
g.zonaRequerida(‘‘Madrid-Atocha’’, ‘‘Valencia’’);
g.zonaRequerida(‘‘Madrid-Atocha’’, ‘‘San Rafael’’);
El sistema deberı́a indicar que la estación de “Valencia” no existe en el sistema, y posteriormente indicar que el recorrido
entre “Madrid-Atocha” y “San Rafael” requiere un abono adscrito a la zona B2.

13
 Fechas y normas de entrega

5.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 etapa.

Finales de Abril. Realización de la segunda etapa.

Mediados de Mayo. Realización de la tercera etapa.

5.2. Normas de entrega

La práctica se entregará a través de la tarea definida en el entorno virtual de la asignatura. Cada alumno creará y com-
primirá una carpeta nombrada con el DNI y primer apellido separados por un guión (”8345385X-gonzalez”). Esta carpeta
contendrá:

Una memoria de no más de 6 hojas donde se explique la especificación y el diseño (etapa 0, ver ??) realizados en cada
parte de la práctica.

Los ficheros .java, sin caracteres especiales; por ejemplo “ñ” o tildes.

NOTA IMPORTANTE: Los nombres de los ficheros y carpetas/paquetes que compongan la práctica entregada, deben con-
tener 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 utilizarse otros, tales como tildes o sı́mbolos.
Los tutores de la asignatura deberán evaluar las prácticas en el entorno virtual antes del 17 de Mayo.
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:

1. 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)

2. Establecer un dı́a de revisión de prácticas (previo al perı́odo 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 deben ser tal y como se definen en este enunciado.

14
 Evaluación de la práctica

5.3. Evaluación de la práctica

Las prácticas tienen carácter INDIVIDUAL, para evitar posibles copias todas las prácticas pasarán por un software
detector de ejemplares similares. 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.
Es requisito indispensable para aprobar el examen, la asistencia a las 3 sesiones obligatorias de la práctica, ası́
como superar la propia práctica. El informe del tutor se considera a efectos de subir nota.
Las prácticas NO se guardan de un curso para otro.

5.4. Preguntas al equipo docente

El equipo docente atenderá preguntas de carácter metodológico y de diseño, preferentemente a través de los foros del
curso virtual de la asignatura. Las preguntas relativas a la instalación del entorno de desarrollo, puesta en funcionamiento y
errores de compilación deben ser remitidas a los tutores de los centros asociados.
Felisa Verdejo Maillo, Catedrática de Universidad
Tutorı́as: Jueves de 11:00 a 13:00h. y de 15:00 a 17:00 h.
Teléfono: 91 398 64 84
Mail: felisa@lsi.uned.es
Enrique Amigó Cabrera, Profesor Contratado Doctor
Tutorı́as: Jueves de 15:00 a 19:00
Teléfono: 91 398 86 51
Mail: enrique@lsi.uned.es
Victor Fresno Fernández, Profesor Contratado Doctor
Tutorı́as: Jueves de 15:00 a 19:00
Teléfono: 91 398 82 17
Mail: vfresno@lsi.uned.es
Roberto Centeno Sánchez, Profesor Ayudante Doctor
Tutorı́as: Jueves de 11:00 a 13:00h. y de 15:00 a 17:00 h.
Teléfono: 91 398 96 96
Mail: rcenteno@lsi.uned.es

15
 Apéndices

El siguiente código captura la fecha actual y le añade 30 dı́as:

import java.util.*;
public class CalendarExample {
public static void main(String[] args) {
Calendar c=Calendar.getInstance();
Date d = c.getTime();
System.out.println(‘‘La Fecha actual es: ’’+ d);
System.out.println();
c.add(Calendar.DAY OF YEAR, 30);
d = c.getTime();
System.out.println(‘‘La Fecha actual mas treinta dias es: ’’ + d);
System.out.println();
}
}

16