Examen Final Junio 2010 (2010)

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 2010
Páginas 10
Fecha de subida 17/09/2014
Descargas 0
Subido por

Vista previa del texto

EXAMEN FINAL Metodología y Programación Orientada a Objetos.
Curso 2009-2010. Cuatrimestre primavera. 11 de Junio de 2010 1. (1.5 PUNTOS) Responded brevemente a las siguientes preguntas: a. ¿Hereda una subclase todos los métodos de la superclase?. ¿Y sus atributos? Hereda todos los atributos y todos los métodos excepto los constructores.
b. ¿Ante qué nos encontramos cuando una o varias subclases tienen diferente código en uno de los métodos heredados de su superclase?.
Ante un método polimórfico.
c. Java puede implementar los conceptos abstractos mediante clases abstractas o interfaces ¿Qué es lo que determina que se use una u otro?.
Las clases abstractas se utilizan cuando hay atributos comunes a todas las subclases. En caso contrario se utilizan los interfaces.
d. Una clase A y una clase B tienen una relación bidireccional de 1 a muchos, esto es un objeto A está conectado con muchos de B. ¿Qué tipo de atributo debe aparecer en A para implementar esa relación, si no importa el orden de los objetos B relacionados con el objeto A?¿y si os objetos B relacionados con el objeto A tienen un nombre y debe accederse a ellos por el nombre? En el primer caso en A debe aparecer un atributo que sea un conjunto de objetos instancias de B. En el segundo debe aparecer un mapa de objetos instancias de B e. En un programa se define una superclase A y una subclase B. B añade a los métodos heredados de A el método f(), que A no tiene. A la vista de lo anterior, ¿es sintácticamente correcto el siguiente trozo de código?¿Por qué? ... … … … A a = new B() ; operar(a) ; ... … … … public void operar(A c){ c.f() ; ………… } El compilador lanzaría un error de compilación. El código de operar() indica que el argumento es una instancia de A y A NO tiene definida la función f(). Aunque en la invocación a la función se pasee un objeto instancia de B (que por herencia es también un objeto instancia de A), el código de la propia función deja claro que el tratamiento del argumento es el de una instancia de A, y esta clase no dispone de f().
PROBLEMA.
Una agencia inmobiliaria 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 inmuebles que están disponibles en cada una de las varias ciudades en las que opera. Debe guardar el nombre de cada ciudad y el de su país.
R2: debe guardar información de los clientes que viven en cada una de las mencionadas ciudades.
R3: debe reconocer inicialmente dos tipos de clientes: el interesado en comprar y el interesado en vender.
R4: de cada cliente, sea del tipo que sea, interesa controlar el nombre, dirección, teléfono y la ciudad en la que vive. Del comprador interesa controlar también el número de visitas realizadas a inmuebles en venta.
R5: en el caso de un cliente interesado en vender, la aplicación gestionará también los inmuebles que quiere vender.
R6: debe reconocer inicialmente dos tipos de inmuebles: las viviendas y los locales comerciales.
R7: de cada inmueble se desea controlar en todo momento su dirección, superficie en metros cuadrados, el número de días que hace que está en venta y un precio base. A cada inmueble se le asigna un código alfanumérico único. De las viviendas interesa controlar si disponen de la correspondiente cédula de habitabilidad.
R8: debe guardar información de las visitas programadas a inmuebles actualmente programadas (5 como máximo) para cada comprador. Una vez el comprador la ha realizado, ésta se elimina del sistema. De cada visita programada debe guardar la fecha (texto en formato dd/mm/aaaa), la hora (texto en formato hh:mm) y el precio que el inmueble tenga en ese momento (calculado según las reglas especificadas en R9).
R9: el precio de un inmueble se calcula según su tipo aplicando las expresiones y reglas que se detallan a continuación: - Precio de vivienda = precio base + (superficie– días en venta)* 10000 Precio del local comercial = precio base + (superficie*2 - días en venta)*5000 Condición adicional para ambos tipos: el precio de la vivienda NUNCA podrá ser menor que el precio base.
R10: debe poder consultarse los clientes y las ciudades por su nombre y los inmuebles por su código.
A continuación se muestra un diagrama de clases parcial (faltan algunas clases, algunos atributos y algunas relaciones entre clases) de la aplicación.
El diagrama de clases se deriva del texto de los requisitos siguiendo las técnicas presentadas en clase para la derivación de dichos diagramas a partir del texto de los casos de uso.
Por ejemplo, las clases Inmueble y Ciudad aparecen en el diagrama anterior por el texto de R1 ya que en él se mencionan los conceptos “inmueble” y “ciudad” (sustantivos –similar técnica a la usada con los casos de uso). La relación existente entre ambas clases (incluyendo cardinalidad) se extrae del mismo R1 (“inmuebles que están disponibles en cada una de las ciudades” –verbo que relaciona dos sustantivos: similar técnica que con los casos de uso).
2. (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 Controlador solo tienen las relaciones mostradas.
c. Añadid a cada clase los atributos que deduzcáis de los requisitos, indicando sus modificadores de acceso. Para prívate usad ‘–‘, para public ‘+’ y para protected ‘#’.
d. El requisito R9 especifica dos formas distintas de calcular el precio de un inmueble. ¿Cómo se implementa en Orientación a Objetos tal especificación? Se implementa mediante polimorfismo: cada subclase define su propia versión de calcularPrecio().
3. (2 PUNTOS) A partir del diagrama UML resultante en el apartado anterior, escribid, para todas las clases, excepto para InterfazUsuario, la parte de código de la definición de comenzando con el “public class….” incluyendo solamente la declaración de los todos los atributos de las clases, incluyendo aquellos que aparecen al implementar las relaciones.
public class Controlador{ private Map ciudades ; private Map clientes ; private InterfazaUsuario iu ; ... ... ... ... ... ...
} public class Cliente{ private String nombre ; private string direccion ; private String telefono ; private Ciudad ciudad ; ... ... ... ... ... ...
} public class Ciudad{ private private private private String nombre ; String pais ; List clientes ; Map inmuebles ; ... ... ... ... ... ...
} public abstract class Inmueble{ private String id ; private String direccion ; private int superficie ; private int diasEnVenta ; private float precioBase ; private String ciudad ; private List visitasProgramadas ; private Vendedor vendedor ; ... ... ... ... ... ...
} public class VisitaProgramada { private String fecha ; private String hora ; private Inmueble inmueble ; private Comprador comprador ; ... ... ... ... ... ...
} public class Comprador extends Cliente{ private int numVisitas ; private List visitasProgramadas ; //vector admisible. numero máximo de visitas: 5 ... ... ... ... ... ...
} public class Vendedor extends Cliente{ private List inmueblesEnVenta ; ... ... ... ... ... ...
} public class Local extends Inmueble{ ... ... ... ... ... ...
} public class Vivienda extends Inmueble{ private boolean cedula ; ... ... ... ... ... ...
} La clase InterfazUsuario gestionará un menú que presentará al usuario una serie de opciones (casos de uso de la aplicación): 1. Dar de alta a un nuevo cliente.
2. Dar de alta un nuevo inmueble.
3. Dada una ciudad, listar todos los inmuebles cuyo precio sea menor que un cierto valor.
4. Concertar una visita de un comprador a un inmueble (identificado por el código) de una cierta ciudad, en una fecha y hora determinada. Las visitas a un inmueble no pueden solaparse. Como se ha mencionado antes un comprador no puede tener más de 5 visitas programadas.
5. Borrar una visita pendiente (porque se ha hecho o porque se ha anulado).
6. Listar las visitas pendientes para una cierta fecha en una ciudad determinada.
4. (1,5 PUNTOS) Desarrollad de forma completa EL CASO DE USO 4. Sugerencia: usad los ejemplos desarrollados en clase como guía de estilo.
LO QUE SIGUE ES UNA DE LAS POSIBLES ALTERNATIVAS: ACTORES: Usuario PRECONDICIONES: El usuario ha seleccionado opción de programar nueva visita POSTCONDICIONES: La visita programada ha sido generada.
ESCENARIO PRINCIPAL: 1. Usuario entra el nombre de la ciudad.
2. Usuario entra codigo de inmueble.
3. Usuario entra fecha y hora de visita.
4. Usuario entra nombre de comprador.
5. Sistema comprueba que el comprador existe.
6. Sistema comprueba que el comprador no tiene 5 visitas pendientes.
7. Sistema comprueba que la agencia opera en esa ciudad.
8. Sistema comprueba que el inmueble existe.
9. Sistema comprueba que no hay otra visita programada en la misma fecha y a la misma hora.
10. Sistema crea una nueva visita programada y la anota entre las visitas al inmueble y las visitas programadas para el comprador.
ESCENARIOS ALTERNATIVOS: 5.a Sistema comprueba que el comprador NO existe.
1. Sistema advierte al usuario.
2. Usuario confirma que quiere proponer otro comprador 3. Volver a paso 4 del escenario principal 2.a Usuario confirma que no desea crear visita programada 1. Sistema vuelve a menú principal.
6.a Sistema comprueba que el comprador tiene 5 visitas programadas pendientes 1. Sistema advierte al usuario.
2. Volver a menú principal.
7.a Sistema comprueba que la agencia NO opera en esa ciudad.
programadas 1. Sistema advierte al usuario.
2. Usuario confirma que quiere proponer otra ciudad 3. Volver a paso 1 del escenario principal 2.a Usuario confirma que no desea crear visita programada 1. Sistema vuelve a menú principal.
8.a Sistema comprueba que el inmueble NO existe.
1. Sistema advierte al usuario.
2. Usuario confirma que quiere proponer otro codigo 3. Volver a paso 2 del escenario principal 2.a Usuario confirma que no desea crear visita programada 1. Sistema vuelve a menú principal.
9.a Sistema comprueba que se solapa otra visita.
1. Sistema advierte al usuario.
2. Usuario confirma que quiere proponer otra fecha y hora 3. Volver a paso 3 del escenario principal.
2.a Usuario confirma que no desea crear una visita programada 1. Sisema vuelve a menú principal.
5. (1 PUNTO) 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 visita programada sin problemas.
A modo de ayuda, se os comenta que el proceso de diseño llega a la conclusión de que cuando el usuario haya seleccionado esta opción y pasado los datos al interfaz de usuario, éste invocará al siguiente método del Controlador: public VisitaProgramada programaVisita(String nombreComprador, String códigoInmueble, String fecha, String hora) ; String ciudad, Dicho método admite los argumentos mostrados y crea (si puede) y devuelve la visita programada.
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.
consigueComprador(): Patrón experto. El controlador tiene acceso a un contenedor con todos los clientes (compradores y vendedores).
compruebaNumeroDeVisitas(): Patrón experto: es el objeto Comprador el que tiene acceso a todas las visitas programadas para él/ella.
getCiudad(): Patrón experto: el controlador tiene acceso a todas las ciudades en las que la agencia gestiona algún inmueble.
getInmueble(): Patrón experto: la ciudad tiene acceso a todos los inmuebles que la agencia gestiona en esa ciudad.
compruebaNoSolapamiento(): Patrón experto: 6.
• El objeto Inmueble tiene acceso a todas las visitas programadas para ese inmueble.
• El objeto Comprador tiene acceso a todas las visitas programadas para el comprador / la compradora. No debe haber solape con ninguna de las visitas programadas.
(1 PUNTO) Detallad completamente las cabeceras de las funciones que hayáis identificado en la pregunta 5. Especificad cada una de ellas de forma análoga a como se hace en el javadoc.
public Comprador consigueComprador(String cln) ; Método de Controlador.
Busca entre los compradores gestionados aquel cuyo nombre coincide con el argumento Retorna: comprador cuyo nombre coincide con el argumento.
public void compruebaNumeroDeVisitas() throws NoMasVisitasException; Método de Comprador.
Comprueba si el número de visitas programadas para ese comprador es inferior a 5.
Lanza: excepción si hay 5 visitas programadas.
Patrón experto: es el objeto Comprador el que tiene acceso a todas las visitas programadas para él/ella.
NOTA: también podía devolver un boolean y no lanzar una excepción.
public Ciudad getCiudad(String cn) ; Método de Controlador.
Busca entre las ciudades gestionadas aquella cuyo nombre coincide con el argumento Retorna: ciudad cuyo nombre coincide con el argumento.
public Inmueble getInmueble(String in) ; Método de Ciudad.
Busca entre los inmuebles gestionados en una determinada ciudad aquel cuyo código coincide con el argumento Retorna: inmueble cuyo codigo coincide con el argumento.
public void compruebaNoSolapamiento(String fe, String ho) throws VisitaSolapadaException ; Método de Inmueble.
Comprueba que no hay ninguna visita programada a ese inmueble que se solape con la fecha y hora pasadas como argumento Lanza: excepción si se solapa con alguna visita al inmueble ya programada.
NOTA: también podía devolver un boolean y no lanzar una excepción.
public void compruebaNoSolapamiento(String fe, String ho) throws VisitaSolapadaException ; Método de Comprador.
Comprueba que no hay ninguna visita programada para ese comprador que se solape con la fecha y hora pasadas como argumento Lanza: excepción si se solapa con alguna visita ya programada para el comprador.
NOTA: también podía devolver un boolean y no lanzar una excepción.
7. (1 PUNTO) Mostrad las cabeceras de las funciones del apartado 6 después de implementar los escenarios alternativos del caso de uso 4. ¿Debería alterarse la cabecera de programaVisita() después de implementar dichos escenarios alternativos? Si en el ejercicio anterior no se ha hecho que compruebaNoSolapamiento() y compruebaNumeroDeVisitas() devuelvan un boolean o lancen una excepción, debería optarse por una de estas dos soluciones en este apartado.
En lo tocante a las otras posibles situaciones anómalas, las cabeceras de las otras funciones dependería de cómo se implementasen los casos de uso alternativos. El software debería asegurarse de identificar las siguientes situaciones anómalas: 1. La agencia no gestiona inmuebles en la ciudad cuyo nombre ha entrado el usuario. Si el software detecta que getCiudad() devuelve null no hay necesidad de alterar su cabecera.
2. La ciudad no tiene un inmueble con el código pasado por el usuario. Idénticas consideraciones a 1 pero aplicadas a getInmueble().
3. La agencia no gestiona un comprador cuyo nombre sea el pasado por el usuario. Idénticas consideraciones a 1 y 2 pero aplicadas a consigueComprador() ; ...