Programación 3
Universidad de Alicante, 2024–2025
Práctica 2
Peso relativo de está práctica en la nota de prácticas: 20% |
Relaciones entre objetos y gestión de errores
(Utiliza el proyecto base de Eclipse para prácticas para esta práctica. Importa los test que se encuentran más abajo en este enunciado como has hecho en los controles de prácticas.)
Introducción
En esta segunda práctica trabajaremos los conceptos introducidos en
las unidades didácticas 2 (relaciones entre objetos) y 3 (gestión de
errores). La práctica consiste en modelar la relación entre un coche
(Car
), las ruedas del coche (Wheel
) y el tipo
de neumáticos (TyreType
) que se monta en estas ruedas. Para
ello implementaremos las clases y la relaciones entre ellas que podemos
encontrar en el siguiente diagrama de clases y que se describen a
continuación.
Las clases Car
, Wheel
y
TyreType
pertenecen al paquete
es.ua.dlsi.prog3.p2.model
. Todos los métodos de estas
clases deberán comprobar que los parámetros que reciben como argumento
son válidos, es decir, que tienen sentido (p.ej. en
TyreType
no tiene sentido una presión negativa, una
descripción vacía o que la presión mínima sea mayor que la presión
máxima). En caso de que algún parámetro no sea válido, deberán lanzar la
excepción no verificada IllegalArgumentException
e incuir un mensaje descriptivo del error al crear la excepción a
lanzar. Acude a la descripción de cada clase para más detalles sobre la
validez de los argumentos. Excepto donde se indique, no debes comprobar
si los argumentos que son referencias a objetos son
null
.
Importante: si los argumentos de un método no pueden tener valores inválidos (por la propia lógica de la aplicación), obviamente no es necesario hacer ninguna comprobación.
Los nombres de los métodos y atributos, incluso de aquello cuya visibilidad sea privada, deben ser los mismos que aparecen en el diagrama UML.
Deberás hacer copia superficial o profunda en los métodos que así lo requieran en función del tipo de relación entre los objetos de estas clases.
Cuando un método pueda lanzar más de un tipo de excepción, en caso de que concurran dos o más situaciones de error, se debe lanzar la excepción que aparece primero en la descripción del método en este enunciado.
Clase TyreType
La responsabilidad de esta clase es la de almacenar los atributos de los distintos tipos de neumáticos que puedan existir. Se trata de una clase inmutable. Los métodos de esta clase deben cumplir los siguientes contratos:
- El constructor y el constructor de copia inicializan los atributos
de la clase a los valores recibidos como argumento. El constructor
sobrecargado debe lanzar la excepción
IllegalArgumentException
cuando reciba una presión negativa, una descripción vacía o null, o que la presión mínima sea mayor que la presión máxima. - El métodos
toString()
devuelve una cadena que describe el tipo de neumático. Esta cadena contedrá la descripción y las presiones máxima y mínima. El formato de esta cadena lo ilustra el siguiente ejemplo, donde “185/65 R16” es la descripción y “1.5” y “3.5” las presiones mínima y máxima, respectivamente:
TyreType 185/65 R16 [1.5,3.5]
- Los métodos
getMinPressure()
ygetMaxPressure()
devuelve los valores de presión mínima y máxima, respectivamente. - El método
equals(·)
devuelve cierto si y solo si son iguales la descripción y las presiones mínima y máxima.
Clase Wheel
Esta clase representa la rueda de un vehículo a la cual se le puede
asignar un tipo de neumático (TyreType
) y cuyo estado viene
determinado por el tipo de neumático que tiene asignado y la presión a
la que se ha hinchado la rueda.
Los métodos de esta clase debe cumplir los siguientes contratos:
- Los constructores y el constructor de copia de la clase inicializan
sus atributos a partir de los parámetros que reciben. La presión inicial
de la rueda (
pressure
) será de cero, salvo en el constructor de copia que será la de la rueda recibida como argumento. setTyreType(·)
ygetTyreType()
son el getter y el setter que permiten acceder y modificar el tipo de neumático asignado (TyreType
) a la rueda.inflate(double)
actualiza el valor de presión de la rueda (pressure
). Este método lanzará las siguientes excepciones:IllegalArgumentException
si la presión recibida como argumento es menor que cero.NoTyreTypeException
si la rueda no tiene asignada un tipo de neumático (TyreType
).PressureWheelException
si la presión recibida como argumento está fuera de los límites mínimo y máximo para el tipo de neumático asignado.
Clase Car
Esta clase representa un vehículo al cual se le pueden añadir ruedas
(Wheel
) hasta el máximo indicado en la relación.
Los métodos de esta clase debe cumplir los siguientes contratos:
- El método
addWheel(Wheel)
añadirá la rueda (Wheel
) recibida como argumento al coche (Car
) tras comprobar que el número de ruedas no exceda del máximo permitido y que es igual a las ruedas que pudiera haber ya. Este método lanzará las siguientes excepciones:TooManyWheelsException
si no es posible añadir la nueva rueda porque se sobrepasaría el máximo de ruedas permitido.WrongTyreTypeException
si el tipo de neumático de la nueva rueva (TyreType
) no es igual al de las ya existentes. Si las ruedas ya existentes no tienen asignado tipo de neumático (TyreType
) la nueva rueda tampoco deberá tenerlo.
getWheels()
devuelve todas las ruedas del vehículo o unArrayList<Wheel>
vacío si el coche aún no tiene ruedas instaladas.changeTyres(TyreType,double)
cambia los neumáticos de todas las ruedas usando el tipo de neumático (TyreType
) y presión (pressure
) recibidos como argumento. Este método lanzará las siguientes excepciones:IllegalArgumentException
si el parámetro de tipoTyreType
es null.PressureWheelException
si la presión recibida como argumento no es válida. Esta comprobación no deberá hacerse en este método, sino que se capturará la excepción emitida porWheel.inflate(·)
se producirá un mensaje de error por consola y se relanzará la excepción.RuntimeException
en caso de que se produzca cualquier otra situación de error.
Excepciones
Todas las excepciones indicadas en el diagrama UML son excepciones
verificadas (checked exceptions) y todas ellas pertenecerán al
paquete es.ua.dlsi.prog3.p2.exceptions
. Su significado debe
haber quedado claro a lo largo de este enunciado.
Clase PressureWheelException
Debe implementar los métodos declarados en el diagrama UML de más arriba. Estos métodos deben cumplir los siguientes contratos:
- El constructor almacena la presión recibida como argumento en el
atributo privado
pressure
. getMessage()
devuelve una cadena del tipo “Pressure of 3.5 BAR
” donde 3.5 será el valor concreto del atributo privadopressure
.
Pruebas unitarias
Proporcionamos pruebas unitarias en el siguiente fichero que comprueban el adecuado comportamiento de las clases. Es importante que entiendas qué se prueba y cómo se hace.
Documentación
Este apartado no se realizará en el control
Debes incluir en los ficheros fuente todos los comentarios necesarios en formato javadoc. Estos comentarios deben definirse para:
- Ficheros: debe incluir nombre y dni de los autores usando la anotación @author
- Clases: propósito de la clase: mínimo 3 líneas
- Operaciones/métodos: 1 línea para funciones triviales, y un mímimo de 2 líneas, parámetros de entrada, parámetros de salida y funciones dependientes para operaciones más complejas.
- Atributos: propósito de cada uno de ellos: como mínimo 1 línea
Documenta además los siguientes aspectos:
- Indica si los atributos y métodos son de instancia o de clase (excepto constructores).
- Para cada constructor que definas, indica si es constructor por defecto, sobrecargado o constructor de copia.
- Indica si el constructor de copia realiza copia superficial o profunda.
- Indica que estás usando copia defensiva allí donde lo hagas.
Puedes usar un comentario no javadoc cuando sea necesario.
No es necesario generar en HTML la documentación javadoc.
Requisitos mínimos para evaluar la práctica
- La práctica debe poder ejecutarse sin errores de compilación.
- Ninguna operación debe emitir ningún tipo de comentario o mensaje por salida estándar, a menos que se indique lo contrario. Evita también los mensajes por la salida de error.
- Se debe respetar de manera estricta el formato del nombre de todas las propiedades (públicas, protegidas y privadas) de las clases, tanto en cuanto a ámbito de visibilidad como en cuanto a tipo y forma de escritura. En particular se debe respetar escrupulosamente la distinción entre atributos de clase y de instancia, así como las mayúsculas y minúsculas en los identificadores.
- La práctica debe estar suficientemente documentada, de manera que el contenido de la documentación que se genere mediante la herramienta javadoc sea significativo.
Entrega de la práctica
La práctica se entrega en el servidor de prácticas del DLSI.
Debes subir allí un archivo comprimido con tu código fuente (sólo archivos .java). En un terminal, sitúate en el directorio ‘src’ de tu proyecto Eclipse e introduce la orden
tar czvf prog3-p2.tgz *
Sube este fichero prog3-p2.tgz
al servidor de prácticas.
Sigue las instrucciones de la página para entrar como usuario y subir tu
trabajo.
Esta entrega sólo sirve para que se evalue la parte de documentación y obtener el resultado del oráculo. ## Evaluación
La corrección de la práctica es automática. Esto significa que se deben respetar estrictamente los formatos de entrada y salida especificados en los enunciados, así como la interfaz pública de las clases, tanto en la signatura de los métodos (nombre del método, número, tipo y orden de los argumentos de entrada y el tipo devuelto) como en el funcionamiento de éstos. Así, por ejemplo, el método Clase(int,int) debe tener exactamente dos argumentos de tipo int.
Tienes más información sobre el sistema de evaluación de prácticas en la ficha de la asignatura.
Además de la corrección automática, se va a utilizar una aplicación detectora de plagios. Se indica a continuación la normativa aplicable de la Escuela Politécnica Superior de la Universidad de Alicante en caso de plagio:
“Los trabajos teórico/prácticos realizados han de ser originales. La detección de copia o plagio supondrá la calificación de”0” en la prueba correspondiente. Se informará la dirección de Departamento y de la EPS sobre esta incidencia. La reiteración en la conducta en esta u otra asignatura conllevará la notificación al vicerrectorado correspondiente de las faltas cometidas para que estudien el caso y sancionen según la legislación vigente”. |
Aclaraciones
- Aunque no se recomienda, se pueden añadir los atributos y métodos privados que se considere oportuno a las clases. No obstante, eso no exime de implementar TODOS los métodos presentes en el enunciado, ni de asegurarse de que funcionan tal y como se espera, incluso si no se utilizan nunca en la implementación de la práctica.
- Cualquier aclaración adicional aparecerá en este enunciado.