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.

Figura 1. Diagrama de clases UML.
Figura 1. Diagrama de clases UML.

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() y getMaxPressure() 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(·) y getTyreType() 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 un ArrayList<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 tipo TyreType 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 por Wheel.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 privado pressure.

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.