Examen Final Junio 2011 (2011)

Examen Español
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ingeniería de Sistemas de Telecomunicación - 1º curso
Asignatura Metodologia y Programacion Orientada a Objetos
Año del apunte 2011
Páginas 10
Fecha de subida 17/09/2014
Descargas 0
Subido por

Vista previa del texto

MOO. Solución examen final. Junio 2011 Criterios de corrección utilizados por todos los profesores PREGUNTAS 1.1 A 2.2: TODO BIEN: 0,25 1 FALLO: 0,125 2 FALLOS O MAS: 0 PREGUNTA 3: Se comienza contabilizando 2 puntos. Se anotan los errores y se descuenta la cantidad indicada debajo. Cualquier otro tipo de error, a consideración de quien corrige.
1. No identificar herencia entre establecimiento y sus tipos o poner relación de herencia donde no debe haberla: -1 punto 2. Se pierde completamente una relación o se añade otra que no se justifica bien: -0.2 por error.
3. Se pierde una dirección de una relación: -0.1 por error 4. Se pone mal una multiplicidad: -0.1 por error.
5. Se pierde una clase o se añade una que claramente es errónea: -0.3 por error 6. Se pierde un atributo o se añade uno que claramente es erróneo: -0.1 por error 7. Se pone el el diagrama un atributo que es una implementación de una relación (por ejemplo, poner HashMap establecimientos): -0.2 por error 8. Se ponen atributos públicos que deberían ser privados o protegidos: -0.1 por atributo PREGUNTA 4: Idéntico procedimiento.
1. Se ponen atributos públicos que deberían ser privados o protegidos: -0.1 por atributo 2. Se implementa una relación a muchos con una referencia a un objeto: -0.3 por error.
3. Se implementa una relación a uno con un vector, lista, diccionario o conjunto: -0.3 por error.
4. Se define una clase como private en lugar de public: -0.2 por error 5. Se pierde algun atributo del diagrama de clases: -0.1 por error 6. Se pierde algun atributo resultante de la implementación de una relación existente en el diagrama UML: -0.3 por error 7. Se define un atributo como static cuando debería ser normal o viceversa: -0.1 por error 8. Se añade un atributo claramente erróneo: -0.1 por error.
PREGUNTA 5: 1. APARTADO a): 0.1. APARTADO b): 0.8 APARTADO c): 0.1 Puntuación del código en b): a consideración de quien corrige.
PREGUNTA 6: Idéntico a 3 con criterios que siguen. Si aparecen errores no listados debajo, a consideración de quien corrige.
1. FALTA UN PASO O SOBRA UN PASO O HAY UN PASO ERRÓNEO EN UN ESCENARIO: entre -0.1 y -0.2 por error dependiendo de lo grave que sea.
2. FALTA UN ESCENARIO ALTERNATIVO: -0.3 3. EL ESCENARIO ALTERNATIVO SE IDENTIFICA COMO ALTERNATIVA A UN PASO PERO ESA ASIGNACIÓN ES ERRÓNEA (EN REALIDAD ES ALTERNATIVO A OTRO PASO DISTINTO): -0.1 4. NO SE SIGUE LA NOTACION EXPLICADA EN CLASE: -0.1 SI LA NOTACION USADAP PERMITE ENTENDER LA SECUENCIA DE LOS PASOS Y DE QUÉ PASOS SON ALTERNATIVAS LOS ESCENARIOS ALTERNATIVOS, 0.3 si la notación no permite lo anterior.
5. NO QUEDA CLARO QUE SE HACE CUANDO SE ACABA LA EJECUCION DE UN ESCENARIO ALTERNATIVO O SE ESPECIFICA UN COMPORTAMIENTO ERRÓNEO AL FINALIZAR DICHO ESCENARIO: -0.1 6. FALLO EN PRECONDICIONES/POSTCONDICIONES: -0.1 7. COMPROBACIÓN DE QUE SE CUMPLE ALGO QUE APARECE COMO PRECONDICION: -0.1 CUALQUIER OTRO FALLO: a consideración de quien corrige.
Enunciado del exámen 1. (0.5 PUNTOS) Enmarcad con un círculo las sentencias que son ciertas en las listas que se muestran a continuación, descartando las que son falsas (para cada lista pueden haber varias sentencias correctas o ninguna).
1. Sobre herencia: a. Desde una subclase podemos acceder a los atributos privados de la superclase.
b. Desde una subclase podemos acceder a todos los métodos de la superclase exceptuando los métodos privados.
c. El constructor de la subclase sólo puede llamar al constructor de la superclase si ésta es abstracta.
d. Una subclase no puede ser superclase de otras.
2. Sobre polimorfismo: a. Si en una jerarquía de herencia el comportamiento definido por cierto método es ligeramente diferente para cada una de las subclases de la misma superclase, dicho método será polimórfico.
b. Utilizando una variable de referencia de un tipo de interface determinada podemos invocar métodos polimórficos sobre cualquier tipo de objeto que implemente dicha interface.
c. En una jerarquía de herencia, un método polimórfico debe ser definido en todas las subclases que la componen, aunque no es estrictamente necesario hacerlo en su superclase.
d. El método public Iterator<E> iterator(), que podemos invocar sobre una ArrayList para obtener un iterador que nos permita recorrerla, es un método polimórfico.
2. (0.5 PUNTOS) Rellenad los huecos con la respuesta adecuada según el contexto que se proporciona: 1. Sobre colecciones de datos: a. Para almacenar un conjunto de ciudades, identificables por su nombre, utilizaríamos un/a Map b. Para almacenar las páginas de un calendario, cada una de las cuales identifica un mes del año, utilizaríamos un/a vector estático c. Para almacenar los números cantados a lo largo de una partida de bingo utilizaríamos un/a Set.
d. Para implementar la cola de personas esperando a ser atendidas en una oficina del INEM utilizaríamos un/a List.
2. Sobre nomenclatura en diagramas de clases UML: a. Para reflejar una relación parte-todo, donde si se destruye el todo las partes permanecen intactas, utilizaríamos una relación de agregación débil.
b. Una asociación, donde la clase origen y destino son la misma, la llamamos asociación reflexiva.
c. Si tenemos una clase con ciertos atributos y algún método para el cual aún no podemos proporcionar implementación, la llamamos clase abstracta.
d. La cardinalidad que utilizaríamos para indicar el número de jugadores de una partida de parchís sería 2..4 PROBLEMA.
Una agencia de viajes desea disponer de una sencilla aplicación informática para gestionar sus operaciones. A continuación se listan una serie de requisitos que la aplicación debe satisfacer: R1: debe guardar información sobre los viajes que gestionen para cada cliente. La aplicación deberá poder gestionar simultáneamente hasta un máximo de 6 viajes distintos para un determinado cliente.
R2: debe guardar información de los clientes para quienes se gestionan los viajes.
R3: de cada cliente, interesa controlar el nombre, dirección, teléfono, DNI y la ciudad en la que vive.
R4: para cada viaje la aplicación controlará un identificador único (String), las reservas de estancia y los vuelos que haya que realizar durante ese viaje. El sistema deberá permitir elegir alojamiento de entre un grupo de establecimientos a los que el controlador tiene acceso durante la ejecución del programa. El sistema deberá permitir elegir vuelo de entre un grupo de vuelos a los que el controlador tiene acceso durante la ejecución del programa.
R5: de cada reserva de estancia la aplicación debe controlar la ciudad, la fecha de llegada, y la fecha de salida. Las fechas se codifican como un String.
R6: adicionalmente, para cada reserva, la aplicación debe permitir controlar el establecimiento en la que se ha realizado la reserva.
R7: para cada establecimiento, la aplicación controlará el precio ofrecido por el propio alojamiento y su nombre. Un mismo establecimiento podrá formar parte de diferentes reservas.
R8: la aplicación debe reconocer tres tipos de establecimientos: apartamento, hotel y albergue.
R9: en los albergues, la aplicación debe controlar además si se necesita un carnet de alberguista para pernoctar o no.
R10: de cada vuelo, la aplicación debe controlar su identificador (un String), la hora de salida, la hora de llegada prevista y el precio ofrecido por la compañía aérea. También debe controlar los dos aeropuertos, el de salida y el de llegada.
R11: de cada aeropuerto, la aplicación debe controlar su identificador único (un String) y su nombre.
R12: debe permitir poder listar los detalles de todos los viajes creados para un cliente.
R13: debe permitir poder listar los detalles del cliente para el que se está gestionando un viaje determinado.
R14: El programa debe permitir calcular el precio total de cada viaje como la suma de los precios del viaje más el precio de los establecimientos. Estos precios se calculan de forma distinta, debido a la diferente comisión que la agencia cobra al cliente. A continuación se muestran los detalles: Apartamento: precio a pagar por cliente = precio requerido por alojamiento * 1,15 Hotel: precio a pagar por cliente = precio requerido por alojamiento * 1,1 Albergue: precio a pagar por cliente = precio requerido por alojamiento * 1,02 Vuelo: precio a pagar por cliente = precio requerido por compañía aérea * 1,1 A continuación se muestra un diagrama de clases parcial (faltan algunas clases, algunos atributos y algunas relaciones entre clases) de la aplicación.
Como podéis observar la clase Establecimiento dispone del siguiente método: public boolean quedanHabitacionesConNCamas (String fechaEntrada, String fechaSalida, int numCamasIndiv, int numCamasDobles) ; Este método permite saber si el establecimiento dispone, para las fechas comprendidas entre fechaEntrada y fechaSalida, de al menos una habitación con el número de camas individuales indicadas por numCamasIndiv, y el número de camas dobles indicadas por numCamasDobles. En lo que concierne a la resolución de este examen, no tenéis que preocuparos por los mecanismos utilizados por dicho método para conocer la información necesaria para poder devolver true o false. Simplemente debéis asumir que podéis invocarlo cuando lo consideréis oportuno y que el valor devuelto será siempre correcto.
La clase Auxiliar contiene el método public static boolean esFechaMayor(String fecha1, String fecha2); Esta función devuelve true si fecha1 y fecha2 contienen representaciones textuales de dos fechas y la fecha representada por fecha 1 es posterior a la representada por fecha2.
3. (2 PUNTOS) Completad el diagrama UML a partir del texto de los requisitos. Para ello: a. Añadid aquellas clases que identifiquéis en los requisitos y no aparezcan en el diagrama.
b. Añadid también las relaciones que consideréis oportunas a partir de dichos requisitos (incluyendo nombre, cardinalidad y direccionalidad en las asociaciones). NOTA: InterfazUsuario y Auxiliar solo tienen las relaciones mostradas. No así el resto de las clases que aparecen en el diagrama.
c. Añadid a cada clase los atributos que deduzcáis de los requisitos, indicando sus modificadores de acceso. Para private usad ‘–‘, para public ‘+’ y para protected ‘#’.
d. El requisito R14 especifica dos formas distintas de calcular el precio de una reserva de alojamiento.
¿Cómo se implementa en Orientación a Objetos tal especificación? 4. (1.5 PUNTOS) A partir del diagrama UML resultante en el apartado anterior, escribid, para todas las clases, excepto para InterfazUsuario y Auxiliar, la parte de código de la definición de comenzando con el “public class….” mostrando solamente la declaración de los todos los atributos de las clases, incluyendo los atributos que aparecen al implementar las relaciones.
5. (1 PUNTO) Se desea construir un método que deposite en un String una representación textual de toda la información concerniente a un viaje, esto es, los detalles completos de todas sus reservas de alojamiento y todos sus vuelos. Se llega a la conclusión de que el método debe tener la cabecera siguiente: public String toString() ; Contestad a las siguientes preguntas: a) ¿En cuál de vuestras clases debería aparecer dicho método? b) Proponed el código del método.
c) ¿Qué otros métodos de qué otras clases sería necesario construir? (No deben programarse, sólo mencionarse) La clase InterfazUsuario gestionará un menú que presentará al usuario una serie de opciones entre los cuales se encuentran(casos de uso de la aplicación): 1. Dar de alta a un nuevo cliente.
2. Crear un nuevo viaje para un cliente.
3. Añadir un vuelo para un viaje.
4. Crear una reserva de una habitación en un establecimiento para un viaje.
5. Mostrar todos los detalles de un viaje.
6. Mostrar todos los viajes de un cliente.
6. (2 PUNTOS) Desarrollad de forma completa EL CASO DE USO 4.
7. (2 PUNTOS) Generad el diagrama de secuencias correspondiente al ESCENARIO PRINCIPAL DEL CASO DE USO 4. El escenario principal es el que conduce a la creación de la reserva y a su incorporación al viaje sin problemas. Comentad brevemente cómo habéis identificado las operaciones que deben construirse, y razonad la asignación de cada función a una cierta clase. NOTA: en este diagrama solo deberían intervenir objetos de las clases que hayáis construido en el diagrama del ejercicio 3.
8. (0.5 PUNTOS) Detallad completamente las cabeceras de las funciones que hayáis identificado en la pregunta 5.
Solución a Ejercicio 3 Algunas mínimas diferencias en direccionalidad de las asociaciones podrían también ser correctas.
Respuesta a la pregunta d: las diferentes maneras de calcular el precio final a partir del precio ofrecido y según el tipo de establecimiento se implementan mediante polimorfismo. Un método calcularPrecio() se definiría como abstracto en la clase Establecimiento, y se redefiniría obligatoriamente en cada una de sus subclases.
Solución a ejercicio 4 public class Controlador { private Map<String,Cliente> clientes; private List<Viaje> viajes; private List<Vuelo> vuelos; private List<Establecimiento> establecimientos; } public class Cliente { private String nombre; private String ciudad; private String DNI; private String telefono; private String Direccion; private List<Viaje> viajes; } public class Viaje { private String id; private Cliente cliente; private List<ReservaEstancia> reservaEstancias; private List<Vuelo> vuelos; } public class ReservaEstancia { private String fechaEntrada; private String fechaSalida; private String ciudad; private Establecimiento establecimiento; } public abstract class Establecimiento { private String nombre; protected String precioOfrecido; private List<ReservaEstancia> reservas; } public class Apartamento extends Establecimiento { } public class Hotel extends Establecimiento { } public class Albergue extends Establecimiento { private boolean carneRequerido; } public class Vuelo { private String id; private String horaSalida, horaLlegada; private double precioOfrecido; private Aeropuerto origen, destino; } public class Aeropuerto { private String identificador; } Solución a ejercicio 5 Pregunta A: debería aparecer en la clase Viaje, puesto que es la que tiene acceso todos los datos requeridos, y de hecho queremos imprimir los datos de un Viaje.
Pregunta B: Una de las posibles soluciones sería la siguiente: public String toString() { String mensaje = "Viaje número " + id + "\n"; mensaje += "­­­­­­­­­­\n"; mensaje += "Datos del cliente:\n" + cliente.toString() + "\n"; mensaje += "­­­­­­­­­­\n"; mensaje += "Datos de las estancias:\n"; Iterator<ReservaEstancia> estIter = reservaEstancias.iterator(); while(estIter.hasNext()) { mensaje += estIter.next().toString() + "\n"; } mensaje += "­­­­­­­­­­\n"; mensaje += "Datos de los vuelos:\n"; Iterator<Vuelo> vueloIter = vuelos.iterator(); while(vueloIter.hasNext()) { mensaje += vueloIter.next().toString() + "\n"; } return mensaje; } Pregunta C: Para el código concreto de la solución expuesta en B, tan sólo sería necesario definir los métodos toString de las clases Cliente, ReservaEstancia, y Vuelo. Otras soluciones podrían requerir la definición de getters para dichas clases.
Solución a ejercicio 6 NOMBRE DEL CASO DE USO: ReservaEstablecimientoEnViaje ACTORES: usuario PRECONDICIONES: . El usuario ha seleccionado la opción de añadir un establecimiento para un viaje.
. El usuario ha seleccionado el viaje al que la reserva debe añadirse.
POSTCONDICIONES: . El sistema ha generado la reserva con éxito, la ha añadido al viaje y ha creado las relaciones entre la nueva reserva y el establecimiento en el que ésta ha sido realizada.
ESCENARIO PRINCIPAL 1. El usuario introduce el nombre de la ciudad.
2. El Usuario introduce fecha de entrada 3. El usuario introduce fecha de salida 4. El usuario introduce el numero de camas individuales y dobles.
5. Sistema comprueba que el formato de las fechas de entrada y salida es correcto, y que la fecha de salida es mayor a la fecha de entrada.
6. El sistema genera la lista de establecimientos concertados en la ciudad que tienen disponible el número de camas que el usuario ha descrito para las fechas especificadas. La lista es presentada al usuario, incluyendo tipo y requisitos.
7. El usuario selecciona un establecimiento.
8. El sistema comprueba si el establecimiento es un albergue, y si el cliente requiere el carné de alberguista.
9. El sistema crea la reserva.
10. El sistema añade la reserva al viaje.
11. El sistema genera la relación entre la reserva y el establecimiento en cuestión.
ESCENARIOS ALTERNATIVOS.
5.a El sistema comprueba que las fechas de entrada y salida son incorrectas.
1. El sistema avisa al usuario.
2. El sistema propone al usuario introducir otras fechas 3. El usuario acepta introducir otras fechas.
4. El sistema va al paso 2 del escenario principal.
3.a. El usuario no acepta reintroducir las fechas 1. El caso de uso finaliza.
6.a. El sistema no puede generar la lista porque no hay establecimientos concertados en esa ciudad.
1. El sistema avisa al usuario.
2. El caso de uso finaliza.
6.b El sistema no puede generar la lista porque no hay habitaciones disponibles con las caracteristicas de camas indicadas en ningún establecimiento 1. El sistema avisa al usuario.
2. El sistema propone al usuario seleccionar otras fechas u otra cantidad de camas.
3. El usuario acepta cambiar los datos.
4. El sistema vuelve al paso 6 del escenario principal.
3.a. El usuario no acepta reintroducir las fechas y las camas 1. El caso de uso finaliza.
8.a El sistema comprueba que el establecimiento es un Albergue, y requiere carné de alberguista 1. El sistema avisa al usuario y le pide el número de carné.
2. El usuario introduce el número de carné de alberguista.
3. El sistema comprueba que el número de carné es correcto.
4. El sistema va al paso 9 del escenario principal.
2.a. El usuario cancela la operación.
1. El caso de uso finaliza 3.a. El número de carné de alberguista es incorrecto.
1. El sistema notifica al usuario del error.
2. El sistema vuelve al paso 2 del escenario alternativo 8.a.
Solución a ejercicio 7 Solución a ejercicio 8 Clase Controlador: List<Establecimiento> muestraEstablecimientos(String ciudad, String fechaEntrada,  String fechaSalida, int camasIndividuales, int camasDobles) throws  NoEstablecimientosEnCiudadException, NoCamasException; void creaReserva(Establecimiento establecimiento, String fechaEntrada, String  fechaSalida, int camasIndividuales, int camasDobles) throws ReservaException; Clase Establecimiento: boolean isAlbergue(); void addReservaEstancia(ReservaEstancia reserva); Clase Viaje: void addReservaEstancia(ReservaEstancia reserva); ...