Pr´actica Obligatoria Curso 2015/2016

Universidad Nacional de Educación a Distancia
D EPARTAMENTO
DE
L ENGUAJES
Y
S ISTEMAS I NFORM ÁTICOS
Fundamentos de Informática
Práctica Obligatoria
Curso 2015/2016
Índice general
1. Introducción
1.1. Descripción de la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. ETAPA 0 Diseño de la práctica: Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
2. ETAPA 1
2.1. ETAPA 1.1 Orientación a Objetos: La clase Alumno . . .
2.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . .
2.1.2. Requisitos previos . . . . . . . . . . . . . . . .
2.1.3. Enunciado: Implementación de la clase Alumno .
2.2. ETAPA 1.2 Ejecución de Aplicaciones: La clase lanzador
2.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . .
2.2.2. Requisitos previos . . . . . . . . . . . . . . . .
2.2.3. Enunciado: Creación de una clase lanzadora . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
4
4
5
5
6
6
3. ETAPA 2
3.1. ETAPA 2.1 Composición: Grupos y alumnos . . . . . . . . . . . .
3.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Enunciado: Creación de las clases Grupo y Alumno . . . . .
3.2. ETAPA 2.2 Añadiendo aulas, profesores y materias en el sistema . .
3.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . .
3.2.3. Enunciado: Creación de las clases Aula, Profesor y Materia
3.3. ETAPA 2.3: Gestionando la academia . . . . . . . . . . . . . . . .
3.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . .
3.3.3. Enunciado: Implementando la clase Academia . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
7
8
8
8
9
10
10
10
10
4. ETAPA 3
4.1. ETAPA 3.1: Emitiendo facturas . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3. Enunciado: Añadir funcionalidad de facturación . . . . . . . . . .
4.2. ETAPA 3.2: Herencia y Polimorfismo: añadiendo distintos tipos de facturas
4.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3. Enunciado: Implementando el proceso de facturación . . . . . . . .
4.3. ETAPA 3.3: Estadı́sticas sobre el estado de la academia . . . . . . . . . . .
4.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3. Enunciado: Analizando estadı́sticas . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
11
11
11
12
12
12
12
12
13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
Í NDICE GENERAL
5. Fechas y normas de entrega
5.1. Fechas . . . . . . . . . . . .
5.2. Normas de entrega . . . . .
5.3. Evaluación de la práctica . .
5.4. Preguntas al equipo docente
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
15
15
Capı́tulo 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 para programar utilizando el paradigma orientado a objetos es el de objeto. En este paradigma, todo está basado
en los objetos, que tienen vida cuando nuestro programa está en ejecución. Por tanto, un programa Java se diseñará en base
a objetos, que además, podrán 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 esta 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 de la práctica
El objetivo principal de esta práctica es el diseño e implementación de una parte de la funcionalidad de un gestor de una
academia donde se imparten clases de música. En general, se imparten en la academia muchas clases de pocos alumnos o
incluso particulares, de una gran diversidad de instrumentos y técnicas como solfeo, coro, armonı́a, contrapunto, improvisación, etc. Por ello, la academia dispone de muchos profesores y aulas con diferentes medios (piano, equipo de música,
etc). En el sistema que vamos a desarrollar nos centraremos en operaciones básicas de consulta y actualización, como dar de
alta materias, alumnos, profesores o clases, o consultar materias impartidas en la academia, por un determinado profesor o
recibidas por un alumno. El sistema también abordará el proceso de facturación de las clases impartidas a cada alumno de la
academia.
Para la realización de la práctica seguiremos un enfoque iterativo, es decir, 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 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
solicita, y organizar adecuadamente el estudio de la asignatura.
1.2.
ETAPA 0 Diseño de la práctica: Diagrama de clases
Cuando afrontamos el desarrollo de una aplicación informática, es indispensable y necesaria una fase previa donde se
analicen los requisitos y diseñen las entidades, en nuestro caso clases, necesarias para llevar a cabo las funcionalidades
requeridas, ası́ como la relación entre las mismas. Para llevar a cabo esta tarea, 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 cómo se relacionan entre ellas,
para posteriormente comenzar la fase de implementación de las mismas. Por tanto, se debe realizar un primer diagrama de
clases en la primera etapa, que posteriormente se irá refinando y/o modificando en cada una de las siguientes etapas, siempre
como requisito previo a comenzar a implementar el código de la etapa.
El diagrama de clases obtenido en la última etapa debe ser entregado junto al código de la práctica.
3
Capı́tulo 2
ETAPA 1
2.1.
ETAPA 1.1 Orientación a Objetos: La clase Alumno
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
sección 1.1 la práctica consiste en el diseño e implementación de un gestor de una academia de música. Por tanto, una entidad
básica en este dominio es el alumno. Es decir, nuestro gestor debe ser capaz de manejar información relativa a los alumnos
a los que se imparten las diferentes clases. Para ello, vamos a empezar la práctica diseñando e implementando una clase
denominada Alumno, que nos permita encapsular la información asociada a cada uno de los alumnos que asisten a las clases
en la academia. De esta manera, cada alumno concreto será modelado como un objeto de dicha clase, con sus caracterı́sticas
especı́ficas para los atributos definidos por la propia clase.
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 el apartado 6.13.1 y 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 Alumno
En esta primera etapa realizaremos el modelado inicial de alguno de los componentes principales del sistema. Como ya
hemos explicado, uno de estos elementos son los alumnos a los que se imparten las clases, y que como hemos comentado
serán modelados como objetos. Ası́ pues, necesitaremos definir una clase denominada Alumno que nos permita crear las
distintas instancias.
Como punto de partida, en el sistema que queremos implementar cada alumno se caracteriza por los siguientes atributos:
1. Cada alumno se identifica por su nombre y apellidos.
2. También habrá que considerar su fecha de nacimiento y teléfono de contacto, ası́ como su dirección.
3. El sistema deberá tener constancia de si el alumno pertenece a una familia numerosa y si está empadronado en el
municipio.
Además, un objeto de esta clase Alumno nos 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
modificarlo, respectivamente.
Asimismo, deberá existir un método, llamado mostrarInfoAlumno(), que escriba por pantalla la información de un alumno
concreto, con un formato legible como, por ejemplo, el mostrado en la figura 2.1. Para ello, podemos hacer uso del método
System.out.println() sobre el que podemos encontrar información en el capı́tulo 2.9 del libro de texto.
4
2.2. ETAPA 1.2 E JECUCI ÓN DE A PLICACIONES : L A CLASE LANZADOR
Nombre: Fernando
Apellidos: Gonzalez Picon
Fecha de nacimiento: 4 de abril de 2003
Teléfono: 609782341
Dirección: Calle del molino 23, Villanueval del Codillo
Familia numerosa: Si
Empadronado: No
Figura 2.1: Formato de salida por pantalla con la información de un alumno
RECOMENDACIÓN: jugar con BlueJ creando objetos de la clase Alumno, modificando el valor de sus atributos,
mostrándolos por pantalla, etc.
2.2.
ETAPA 1.2 Ejecución de Aplicaciones: La clase lanzador
2.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 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.2, donde se muestran varios
objetos del banco de objetos. Cada uno de ellos es inspeccionado mostrando los valores de sus atributos
Figura 2.2: BlueJ con varias figuras geométricas 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 Alumno
que hemos creado, tiene un método para consultar su nombre, 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 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 las clases que los definen, por lo que deberemos usar un método
de clase 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 2.2.2).
5
C AP ÍTULO 2. ETAPA 1
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).
2.2.2.
Requisitos previos
Además de los expuestos en la sección 2.2.1, debe consultarse el libro de texto, capı́tulo 6.15, sobre métodos de clase.
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.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.
2.2.3.
Enunciado: Creación de una clase lanzadora
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 por tanto será la encargada de crear el gestor
de la academia, alumnos, aulas, etc. y de realizar simulaciones de operaciones (todo esto se realizará en posteriores etapas).
En esta etapa debe implementar el método main() y crear unos cuantos alumnos con sus respectivos valores de sus atributos,
para después modificar estos valores mediante los métodos creados para tal efecto. Para ver los cambios realizados puede
utilizar el método mostrarInfoAlumno() creado anteriormente. Ejecute el programa tanto desde BlueJ como desde la lı́nea
de comandos (terminal o sı́mbolo de sistema dependiendo del sistema operativo que utilice).
NOTA IMPORTANTE: La presente práctica debe poderse ejecutar independientemente de BlueJ de cara a su
entrega y corrección.
6
Capı́tulo 3
ETAPA 2
3.1.
ETAPA 2.1 Composición: Grupos y alumnos
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.
Por ejemplo, en la academia en cuestión para la que se desea implementar el sistema, en un grupo se imparte una materia
en una o varias horas de la semana y a ella asisten un conjunto de alumnos. Con el fin realizar la facturación mensual de cada
alumno, el sistema debe conocer qué alumnos asisten a qué grupos.
De este modo, en esta etapa haremos uso de la composición para representar la relación que existe entre cada grupo y los
alumnos que asisten a dicho grupo.
En la figura 3.1 podemos observar la relación de composición que existe entre un grupo y los alumnos que asisten a dicho
grupo. Un grupo tendrá que tener un atributo o campo horario, en el que se indique los dı́as y las horas en las que se imparten,
y una lista de alumnos que asisten. Además una vez implementada esta clase, ya será posible implementar un método capaz
de imprimir en pantalla la información de cada uno de los alumnos del grupo. Este será el método ListarAlumnos.
Por otro lado, 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. Las lecturas de las secciones de 6.3 a 6.6 (ambas inclusive) sobre buenas prácticas en el
diseño de aplicaciones es también recomendable.
3.1.3.
Enunciado: Creación de las clases Grupo y Alumno
RECOMENDACIÓN: Lea primero los requisitos completos antes de tomar decisiones acerca de cómo desarrollar la
solución.
Como hemos introducido previamente, nuestra aplicación va a gestionar una academia de música, donde a cada grupo asistirá
un conjunto de alumnos. Siguiendo el esquema de la figura anterior, en esta fase debe crearse una nueva clase denominada
grupo, con tres atributos: el identificador del grupo (por ejemplo ”primero de piano B”), el horario (por ejemplo ”Jueves y
viernes de 5 a 7”), y la lista de alumnos que asisten al grupo.
Además, deberá implementarse un método sencillo denominado ListarAlumnos que se encargue de imprimir los nombres
y apellidos de cada uno de los alumnos de ese grupo. Para ello, deberá emplearse las estructuras de control de bucle estudiadas
en el tema 7, con el fin de recorrer la lista de alumnos. En este punto es importante tener en cuenta la orientación a objetos.
Es decir, las acciones a realizar por los métodos deben derivarse en la medida de lo posible a la clase correspondiente. Si es
necesario imprimir el nombre del alumno, esto deberı́a realizarlo en la medida de lo posible la propia clase Alumno, en vez
de acceder a su valor e imprimirlo desde una clase externa.
7
C AP ÍTULO 3. ETAPA 2
Figura 3.1: Diagrama de clases representando la relación entre un grupo y los alumnos que asisten a dicho grupo.
Con el fin de poder actualizar la lista de alumnos, la clase grupo deberá contener un método para añadir y otro para
eliminar un determinado alumno. En ambos casos bastará con hacer una llamada al método correspondiente que ofrece por
defecto cualquier lista en Java. Por ejemplo, el método add permite añadir un elemento a una lista. Téngase en cuenta que
para eliminar un alumno será necesario comprobar si coinciden el objeto alumno del parámetro de entrada con alguno de los
alumnos de la lista.
Por último, vamos a modificar el método main() creado en la etapa anterior de tal manera que ahora creemos distintos
grupos y alumnos. A continuación, crear objetos tipo Grupo asignandoles un horario y añadiéndoles alumnos. Inicialice los
valores de todos los atributos mediante los métodos correspondientes. A continuación solicite al sistema que muestre por
pantalla la información de los alumnos del grupo para comprobar que funcione correctamente.
3.2.
ETAPA 2.2 Añadiendo aulas, profesores y materias en el sistema
3.2.1.
Objetivos
En esta fase, seguiremos trabajando el concepto de composición, creando nuevas clases de objetos y relacionándolas entre
sı́. En nuestra academia, un grupo se caracterizará no solo por los alumnos que están matriculados y el horario en el que se
imparte, sino también por el profesor, el aula, y la materia. Esto implica crear nuevas clases, asociándolas mediante la relación
de composición, de forma que unas clases pasan a ser campos de otras.
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.
8
3.2. ETAPA 2.2 A ÑADIENDO AULAS , PROFESORES Y MATERIAS EN EL SISTEMA
3.2.3.
Enunciado: Creación de las clases Aula, Profesor y Materia
RECOMENDACIÓN: Lea primero los requisitos completos antes de tomar decisiones acerca de cómo desarrollar la
solución.
En primer lugar, necesitaremos para esta fase una clase Aula. Esta clase representará el espacio fı́sico donde se imparte
cada una de las materias. Ésta debe tener las cubrir las siguientes restricciones o funcionalidades:
1. El nombre de cada aula puede ser cualquier cadena de caracteres alfanuméricos. Podrı́a llamarse, por ejemplo, ”Sala
123” o ”Sala Roja”.
2. La academia en la que se quiere implantar el sistema es bastante grande. Conviene que el sistema tenga control sobre
el piso de cada aula para ofrecer esta información cuando sea necesario a los alumnos o profesores de la plantilla.
3. El aula deberá contener otro atributo que represente el número de alumnos a los que puede dar cabida dicha aula. Esta
información será importante para gestionar la distribución de alumnos y profesores.
4. Es importante también distinguir entre aulas que disponen de piano y aulas que no, dado que algunas de las materias
impartidas lo requieren (piano, solfeo, canto), mientras que en otras no es necesario (chelo, saxofón).
5. Otro atributo indicará si el aula dispone de medios audiovisuales.
6. Por supuesto, la clase Aula deberá disponer de los métodos necesarios para actualizar sus campos.
La segunda clase que debe incorporarse en el sistema es Materia, siguiendo las siguientes especificaciones:
1. Una materia tiene un nombre, por ejemplo “Música y movimiento II”
2. Una materia tiene una cuota. Es decir, con vistas al proceso de facturación a los alumnos, debe conocerse el precio de
cada materia en términos de cuota mensual.
3. El sistema debe de saber, para cada materia, si requiere medios audiovisuales y/o piano.
4. Para cada materia, deberemos poder conocer qué grupos tiene. Esto supone de nuevo un mecanismo de composión por
medio de estructuras tipo lista.
5. Debe de ser posible actualizar cada uno de sus campos, ası́ como añadir o eliminar un grupo de su lista.
6. Además, la clase Materia debe de disponer de los métodos que sean necesarios para efectuar las funcionalidades que
se especifican en el siguiente apartado.
En tercer lugar, tendremos que introducir también una clase Profesor, siguiendo las siguientes especificaciones:
1. Al igual que un alumno, un profesor tiene un nombre y dos apellidos.
2. Se almacenará el DNI, teléfono de contacto y dirección del profesor.
3. Dispondrá de métodos que permitan la actualización de los campos y mostrar la información del profesor.
Tendremos que revisar el concepto de Grupo de la figura 3.1, introduciendo los campos necesarios para establecer las
relaciones de composición entre las clases creadas en esta fase. Estas relaciones se establecerán siguiendo las siguientes
especificaciones:
1. Un grupo se imparte en un aula determinada.
2. En un grupo se imparte una única cierta materia.
3. En un grupo imparte clase un profesor.
4. Deberá modificarse el método destinado a mostrar en pantalla toda la información relativa al grupo. Se espera que
además de mostrar la información de cada uno de los alumnos, muestre también el tı́tulo de la materia impartida, el
identificador del aula donde se imparte y el nombre del profesor que la imparte.
9
C AP ÍTULO 3. ETAPA 2
Finalmente, tendremos que ampliar también la clase Alumno dado que ahora tendrá asociado también los grupos en los
que está matriculado. Deberá por tanto también añadirse un método que permita incluir o eliminar un grupo en la clase
alumno.
A la hora de desarrollar una aplicación informática es muy importante el manejo de los errores, es decir, contemplar las
situaciones anómalas en las que la propia aplicación se podrá encontrar. Por tanto, además de las funcionalidades pedidas, se
deben manejar, en las propias clases creadas, los casos anómalos producidos por algún error. Ası́ pues, contemplaremos casos
como por ejemplo intentar eliminar un alumno que no está apuntado al grupo, o añadir un alumno que ya ha sido apuntado
anteriormente. Estos casos se deben gestionar informando de esta situación, por ejemplo mostrando un mensaje al usuario,
para lo que se puede utilizar el propio método System.out.println.
En esta etapa se deben documentar todas las clases creadas hasta ahora. En el apartado 5.10.2 del libro de texto se detalla
la mı́nima documentación que se deberı́a incluir.
Por último, vamos a modificar el método main() creado en la etapa anterior de tal manera que ahora creemos distintos
profesores, aulas y materias. A continuación, crear objetos tipo Grupo asignandoles profesores, aulas, materias y alumnos.
Inicialice los valores de todos los atributos mediante los métodos correspondientes. A continuación solicite al sistema que
muestre por pantalla la información del grupo para comprobar que funcione correctamente.
3.3.
ETAPA 2.3: Gestionando la academia
3.3.1.
Objetivos
El objetivo de esta etapa es la implementación del propio gestor de la academia. En concreto vamos a implementar varias
funcionalidades básicas necesarias para administrar y organizar la academia de música. Es decir, actualizar el estado de la
academia añadiendo o eliminando grupos, aulas, materias, profesores o alumnos.
3.3.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.3.3.
Enunciado: Implementando la clase Academia
En esta etapa vamos a crear la clase que nos permita realizar la gestión de la academia. Para ello, debemos crear una nueva
clase denominada Academia siguiendo las siguientes especificaciones:
1. Una academia tiene un nombre, y dirección.
2. Se debe poder imprimir en pantalla un listado de las materias que se ofertan, ası́ como la información de cada uno de
los grupos en donde se imparte: nombre de profesor, nombre de aula y horario.
3. Imprimir en pantalla, por cada materia y grupo, los nombres de los alumnos que asisten a cada grupo.
4. Dar de alta o de baja a un alumno en un grupo.
5. Dar de alta o de baja a un nuevo grupo en una materia.
Ahora modifique la clase Lanzador para crear una academia. Cree también instancias de profesores, materias y aulas. Tras
esto, cree instancias de varios grupos asociándolos a los profesores, materias anteriores. Pida ahora al sistema que imprima
las materias y clases ofertadas. Finalmente, cree instancias de alumnos y pida al sistema que los añada a diferentes grupos.
Pida al sistema que imprima la lista total de alumnos.
Recordamos que además de la funcionalidad solicitada, se deben controlar los posibles errores, en este caso se debe
contemplar, por ejemplo, que un grupo que se desee eliminar no se encuentre en el sistema.
Todos los errores que se detecten se deben gestionar informando al usuario mediante un mensaje, utilizando el
método System.out.println.
Como estrategia de diseño, es importante preservar la cohesión y evitar acoplamiento (capı́tulo 7 del libro). Para
ello, es conveniente encapsular correctamente el código en su clase correspondiente. Por ejemplo, en el caso de que
se desee imprimir la materia y horario de un grupo, deberı́a ser la propia clase Grupo la que contenga un método
destinado a imprimir esta información. Para ello, puede ser necesario implementar nuevos métodos que no aparecen
explı́citamente entre las funcionalidades descritas en este enunciado.
10
Capı́tulo 4
ETAPA 3
4.1.
ETAPA 3.1: Emitiendo facturas
4.1.1.
Objetivos
En esta parte de la práctica vamos a extender el sistema para que nos permita realizar de manera automática la elaboración
de facturas mensuales de los alumnos. Las operaciones de baja o alta de alumnos sólo se realizarán tras la facturación del mes
anterior.
4.1.2.
Requisitos previos
Para llevar a cabo esta última etapa es recomendable un alto dominio de los conceptos de objeto, clase y composición
estudiados hasta este punto.
4.1.3.
Enunciado: Añadir funcionalidad de facturación
Como hemos introducido previamente, para extender la funcionalidad de nuestro programa para cubrir el proceso de facturación, lo primero que necesitamos es la creación de una nueva clase denominada Factura con las siguientes caracterı́sticas
y funcionalidad:
1. Cada factura lleva el nombre del alumno y la fecha correspondiente.
2. Una factura incluye la información del total de la cuota y un desglose por materias impartidas.
Una vez que hemos añadido el concepto de factura a nuestro programa, debemos añadir la funcionalidad que nos permita
emitir las facturas mensualmente de todos los alumnos y almacenarlas en un histórico de facturación.
RECORDATORIO: Recuerde realizar la gestión de los posibles errores, informando al usuario de ellos, ası́ como la
documentación de todas las clases implementadas.
4.2.
ETAPA 3.2: Herencia y Polimorfismo: añadiendo distintos tipos de facturas
4.2.1.
Objetivos
El siguiente paso en la práctica es añadir distintos tipos de factura con un precio reducido. Concretamente, cuando el
alumno sea de familia numerosa, tendrá un descuento del 10 %. Cuando el alumno esté empadronado, ya no tendrá efecto el
que sea de familia numerosa, pero tendrá un descuento del 20 % en todas las materias.
Para este tipo de situaciones, los lenguajes orientados a objetos, como Java, disponen de un mecanismo llamado herencia.
La herencia nos permite construir una nueva clase heredando las caracterı́sticas de una clase ya existente. Por tanto, la clase
“heredera” o “hija” tiene toda la funcionalidad de la clase de la que hereda, clase “padre”, permitiendo además la inclusión de
nuevos métodos y campos para extender dicha funcionalidad. Concretamente, en nuestro caso, las facturas con empadronamiento o de familia numerosa podrán heredar de la clase factura, de forma que lo único que será necesario modificar será el
proceso o método encargado de sumar los costes de cada una de las clases recibidas. Es decir, la funcionalidad de facturación
deberá crear una clase Factura padre o una de las hijas dependiendo de las caracterı́sticas del alumno.
Además de la herencia, en la programación orientada a objetos disponemos del polimorfismo. Como la propia palabra
indica, polimorfismo se refiere a la posibilidad de que un elemento tenga varias formas. En Java podemos tener polimorfismo
en varias entidades: atributos o variables y métodos. En el caso de las variables, el polimorfismo permite que una variable
11
C AP ÍTULO 4. ETAPA 3
pueda contener objetos de diferentes clases, ya sea de la propia clase declarada o de cualquier clase que herede de ésta. En
nuestro caso podremos tener en el historico, facturas de diferente tipo.
El otro tipo de polimorfismo que podemos tener en Java es a nivel de método, de tal forma que una llamada a un método
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. En nuestro caso, las operaciones a realizar en la funcionalidad
de facturación a nivel de la clase gestora no necesita conocer la subclase a la que pertenece la factura en cuestión. Es decir,
una vez creada el objeto de la clase Factura, el resto de operaciones sobre dicha clase como introducir el alumno, la fecha o
las clases recibidas no se ven afectadas por el hecho de que se trate de la versión padre o hija de Factura. De esta forma, la
llamada a calcular precio total ejecutará un método distinto de la clase Factura dependiendo de si ésta pertenece a la clase
padre o a alguna de las dos clases hijas.
4.2.2.
Requisitos previos
Para la realización de esta etapa se requiere haber estudiado el tema 10 del temario detallado de la asignatura, y los
capı́tulos 7 y 8 del libro de texto para todo lo relacionado con la herencia.
Para entender el mecanismo de polimorfismo se requiere haber estudiado los temas 10, 11 y 12 del temario detallado de la
asignatura, que corresponden a las Secciones de la 6.3 a la 6.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.
4.2.3.
Enunciado: Implementando el proceso de facturación
Como ya hemos explicado anteriormente, vamos a añadir a nuestro programa dos nuevos tipos de factura dependiendo
de las caracterı́sticas del alumno. Cuando el alumno sea de familia numerosa, tendrá un descuento del 10 %. Cuando el
alumno esté empadronado, ya no tendrá efecto el que sea de familia numerosa, pero tendrá un descuento del 20 % en todas
las materias.
Teniendo en cuenta esto, debe crear dos nuevas clases Factura empadronamiento y Factura familia numerosa que
agreguen los costes de cada materia recibida dependiendo de las caracterı́sticas del alumno. Por lo tanto, con el fin de evitar
en la mayor medida posible el acoplamiento, las clases hijas deben reimplementar únicamente el método encargado de sumar
las cantidades. Para ello, la clase padre debe de estar implementada de forma que su código se distribuya correctamente entre
distintos métodos.
Téngase en cuenta que en el caso de que esté empadronado, ya no tendrá efecto el que sea de familia numerosa, por lo
que no será necesario mantener el descuento anterior. A continuación, realice el proceso de facturación. En pantalla, deberı́an
imprimirse las facturas con las modificaciones correspondientes.
RECOMENDACIÓN: Se recomienda realizar distintas operaciones con la academia, desde la clase Lanzador del programa, para comprobar que la funcionalidad es correcta y que los posibles errores como consecuencia de búsquedas,
eliminaciones, etc. incorrectas, son manejados y el usuario es informado de los mismos, mediante mensajes en pantalla.
RECORDATORIO: De la misma manera, se recuerda la necesidad de documentar todas las clases generadas hasta el
momento.
4.3.
ETAPA 3.3 (Opcional para las especialidades de Mecánica y Tecnologı́a Industrial): Analizando estadı́sticas de alumnos
4.3.1.
Objetivos
Esta última parte de la práctica es de carácter opcional para las especialidades de Mecánica y Tecnologı́a Industrial y
obligatoria para las otras dos especialidades. El objetivo de esta última etapa se centrará en extender la funcionalidad de
la aplicación de manera que sea posible localizar grupos masificados o unir grupos con escasos alumnos.
4.3.2.
Requisitos previos
Para llevar a cabo esta etapa es recomendable haber estudiado y dominar todos los conceptos estudiados hasta este punto.
12
4.3. ETAPA 3.3: E STAD ÍSTICAS SOBRE EL ESTADO DE LA ACADEMIA
4.3.3.
Enunciado: Analizando estadı́sticas
Los encargados de la academia necesitan tener un control sobre el estado de la misma, con la finalidad de dividir las clases
más masificadas, controlar la carga de los profesores o unir clases con pocos alumnos. El objetivo de esta fase es ser capaz de
implementar consultas más complejas que requieren un manejo más sofisticado de los objetos que conforman el sistema. Se
trata de añadir las siguiente funcionalidades:
1. En general, hay materias de grupos reducidos (menos de 5) y materias de más de 10 alumnos. Para evitar puntos
intermedios, se juntan grupos con menos de 10 pero más de 5 alumnos. Se desea que el sistema sea capaz de identificar
materias para las que haya más de un grupo con entre 5 y 10 alumnos.
2. Listar las clases tales que el número de alumnos supere el 90 % de la capacidad del aula.
13
Capı́tulo 5
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 comprimirá una carpeta nombrada con el DNI y primer apellido separados por guión (”8345385X-gonzalez”). Esta carpeta contendrá:
Una memoria de no más de 6 páginas donde se explique la especificación y el diseño 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 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 utilizarse otros, tales como tildes o sı́mbolos.
Los tutores de la asignatura deberán evaluar en el entorno virtual las prácticas antes del 23 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
5.3. E VALUACI Ó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 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.
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 15:00 a 19:00
Teléfono: 91 398 64 84
Mail: [email protected]
Enrique Amigó Cabrera, Profesor Contratado Doctor
Tutorı́as: Jueves de 15:00 a 19:00
Teléfono: 91 398 86 51
Mail: [email protected]
Victor Fresno Fernández, Profesor Contratado Doctor
Tutorı́as: Jueves de 15:00 a 19:00
Teléfono: 91 398 82 17
Mail: [email protected]
Roberto Centeno Sánchez, Profesor Ayudante Doctor
Tutorı́as: Jueves de 15:00 a 19:00
Teléfono: 91 398 96 96
Mail: [email protected]
15