Examen Final Enero 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 7
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 2010‐2011. Cuatrimestre de otoño. 17 de Enero de 2011  1.   (0,75 PUNTOS) Identificad a continuación las sentencias que son ciertas, descartando las que son  falsas (para cada lista pueden haber varias sentencias correctas o ninguna):  1. Sobre clases y objetos  a. Es una buena práctica no permitir el acceso directo los métodos desde el exterior del objeto.  b. Es una buena práctica no permitir el acceso directo a los atributos desde el exterior del objeto.  c. Sabremos que un método no devuelve valor alguno cuando no haya partícula sintáctica alguna  entre el modificador de acceso y el nombre del método en su cabecera.  d. Una excepción a la regla mencionada en la opción b. se produce cuando los atributos se usan  para definir constantes públicas en un programa.  2. Sobre herencia:  a. En orientación a objetos está permitido que una subclase pueda tener como atributos objetos  instancias de subclases de su misma superclase.  b. Un objeto instancia de una superclase es también instancia de su subclase.  c. Desde un método de la subclase se tiene acceso directo a los atributos privados de su superclase.  d. Si una clase es subclase de otra no puede estar relacionada con otras clases diferente a su  superclase.  3. Sobre abstracción:  a. Los objetos iteradores devueltos por las diferentes implementaciones de lista implementan un  interfaz común pero utilizan mecanismos diferentes para recorrer las listas implementadas.  b. En java el polimorfismo permite generar código que aparentemente ejecuta métodos de objetos  instancia de una superclase cuando en realidad está ejecutando métodos de objetos instancia de  alguna de sus subclases.  c. Una clase abstracta es idéntica en todo a una clase normal excepto por el hecho de que los  diseñadores saben que no deberían invocar a un constructor de dicha clase, aunque si lo hacen, no  hay ningún problema.  d. Los interfaces no permiten implementar polimorfismo  PROBLEMA.  Se pretende diseñar un sistema de monitorización de trenes de metro y de control de incidencias en las  líneas.  A continuación se listan una serie de requisitos que la aplicación debe satisfacer:  R1: El controlador gestionará todas las líneas que conformen el metro de la ciudad en la que la aplicación se  instale. Cada línea tendrá asignado un color como identificador.   R2: El sistema guardará información de las estaciones que forman parte de cada una de las líneas. Para  cada estación, el sistema guardará su nombre.   R3: El sistema guardará información de los tramos de vía que forman parte de cada una de las líneas. Un  tramo de vía conecta dos estaciones. Obviamente, una estación puede ser conectada a varias estaciones  mediante los tramos correspondientes (ello implica que dicha estación forma parte de varias líneas).  R4: Para cada tramo el sistema debe guardar información de su longitud en Km y la velocidad media de  tránsito de los trenes por dicho tramo.  R5: El sistema guardará información de los trenes que circulan por cada una de las líneas.  Cada tren tiene  un identificador alfanumérico. El sistema debe poder guardar el identificador alfanumérico del conductor.  El sistema debe poder monitorizar el tramo por el que el tren esté circulando (si está en marcha) o la  estación en la que se encuentra detenido (cuando así suceda).  R6: El controlador controlará todas aquellas incidencias que se produzcan en el devenir de la actividad del  metro.    R7: Para toda incidencia se calculará un nivel de gravedad, cuyos posibles valores son: LEVE, MODERADA o  ALTA. Además el sistema debe guardar un código identificador  y la hora y el minuto de inicio de la  incidencia.  R8: El sistema gestionará dos tipos de incidencia. El primero será una incidencia de estación. Para las  incidencias de este tipo  el nivel de gravedad se calcula en función del número de líneas de las que la  estación forme parte (1 línea: LEVE; 2 líneas: MODERADA; más de 2 líneas: ALTA).   R9: El segundo tipo de incidencia es la incidencia de circulación parada entre dos estaciones de metro (no  necesariamente contiguas). Para este tipo de incidencias, el nivel de gravedad lo determina el número de  tramos afectados (1 ó 2: LEVE; entre 3 y 5: MODERADA; más de 5: ALTA .  A continuación se muestra un diagrama de clases parcial (faltan clases, atributos,  relaciones entre clases e  incluso cardinalidades) de la aplicación.      2.  (2 PUNTOS) Completad el diagrama UML a partir del texto de los requisitos. Para ello:  a.  Sustituid  los  símbolos  ‘?’  por  la  cardinalidades  pertinentes  en  aquellas  relaciones  del  diagrama  anterior en cuyos extremos aparezcan dichos símbolos.  b. 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).   c. Añadid a cada clase los atributos que deduzcáis de los requisitos.  d.  Los  requisitos  R8  y  R9  especifican  dos  formas  distintas  de  calcular  la  gravedad  de  una  incidencia.  ¿Cómo se implementa en Orientación a Objetos tal especificación?      El  método  +calculaGravedad():  int  es  un  método  polimórfico  que  deberán  sobreescribir  ambas  subclases  de Incidencia, DeEstacion y DeCirculacion, adaptándolo a sus características.    3.    (2,5  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….” correspondiente a la declaración de los todos los atributos de las clases, incluyendo aquellos que  aparecen al implementar las relaciones.   public class InterfazUsuario{ private Controlador controlador; } public class Controlador{ private Map<String, Tren> trenes; private Map<String, Linea> lineas; private Map<String, Incidencia> incidencias; } public class Incidencia{ protected String codigo; protected int hora, minuto; } public class DeEstacion extends Incidencia{ private int numLineas; } public class DeCirculacion extends Incidencia{ private int numTramos; } public class Linea{ private Map<String, Estacion> estaciones; private List<Tramo> tramos; private String color; } public class Estacion{ private String nombre; private List<Tramo> tramos; } public class Tramo{ private double longitud; private double velocidad; private Estacion estaciones[]; } public class Tren{ private String identificador; private Tramo tramo; private Estacion estación; private Conductor conductor; } public class Conductor{ private String identificador; } Los casos de uso de la aplicación serán:  1. Crear una nueva línea de metro sin estaciones.  2. Añadir una estación a una línea.  3. Añadir  un  nuevo  tramo  entre  dos  estaciones  ya  existentes  de  una  línea  pero  no  conectadas  por  ningún tramo.  4. Tren circulando por un tramo.  5. Tren en estación.  6. Listar estados de los trenes de todas las líneas.  7. Listar todas las incidencias de estación de todas las líneas.  8. Listar todas las incidencias de paradas de servicio de todas las líneas.  9. Dar de alta una incidencia.  10. Dar de baja una incidencia.    4. (1,5 PUNTOS) Desarrollad de forma completa  EL CASO DE USO  3.       Número de caso de uso: 3 Nombre del caso de uso: AñadirTramoALinea Precondiciones: usuario ha seleccionado opción de añadir tramo a línea Postcondiciones: tramo creado entre dos estaciones de una línea.
ESCENARIO PRINCIPAL: 1.
2.
3.
4.
5.
6.
7.
8.
Usuario Usuario Usuario Sistema Sistema Sistema Sistema Sistema indica el color de la línea.
indica nombre de estación en un extremo del nuevo tramo.
indica nombre de estación en otro extremo del nuevo tramo.
comprueba que la línea existe.
comprueba que las dos estaciones existen.
comprueba que tramo no existe.
crea nuevo tramo.
conecta las dos estaciones mediante el tramo.
ESCENARIOS ALTERNATIVOS: 4.a Sistema comprueba que la línea no existe.
1. Sistema notifica error.
2. Fin de caso de uso.
5.a Sistema comprueba que alguna de las estaciones no existe 1. Sistema notifica error.
2. Fin de caso de uso.
6.a Sistema comprueba que tramo ya existe 1. Sistema notifica error.
2. Fin del caso de uso.
    5. (1  PUNTO)    Generad  el  diagrama  de  secuencias  correspondiente  al  ESCENARIO  PRINCIPAL  DEL  CASO  DE USO 3. El escenario principal es el que conduce a la del tramo de línea entre dos estaciones dadas. A  modo de ayuda, se os comenta que el proceso de diseño llega a la conclusión de que cuando el desee  crear un nuevo tramo  y pasado los datos pertinentes al interfaz de usuario, éste invocará al siguiente  método del Controlador:  public Tramo crearTramoDeLínea(String nombreEstacion2) ; color, String nombreEstacion1 String Dicho  método  admite  los  argumentos  mostrados  y  crea  (si  puede)  y  devuelve  el  tramo.  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.         Asignación de responsabilidades:    crearTramoDeLinea(): patrón Controlador. El objeto Controlador es el encargado de gestionar los eventos  entrantes al Sistema.  getLinea(): patrón Experto. El objeto Controlador conoce todas las líneas que componen la red de metro.  getEstacion(): patrón Experto. El objeto Linea conoce todas las estaciones que la componen.  getTramo(): patrón Experto. El objeto Linea conoce todas los tramos que la componen.  creaTramo(): patrón Creador. El objeto Linea agrega objetos de tipo Tramo.  addTramo(): patrón Experto. El objeto Estación guarda los tramos que llegan/salen de ella.      6.  (1  PUNTO)  Detallad  completamente  las  cabeceras  de  los  métodos  que  hayáis  identificado  en  la  pregunta  anterior,  indicando  las  clases  que  los  contienen.  Comentad  brevemente  cómo  los  habéis  identificado y razonad su asignación a las clases correspondientes.    Clase Controlador: public Tramo crearTramoDeLinea (String color, String estacion1, String estacion2); public Linea getLinea (String color); Clase Linea: public Estacion getEstacion (String nombre); public Tramo getTramo (String nombre); public Tramo creaTramo(Estacion e1, Estacion e2); Clase Estacion: public void addTramo (Tramo t); Justificación de la pregunta anterior.
asignación de responsabilidades detallada en la     7. (1,25 PUNTOS) Finalmente generad el código de la función crearTramoDeLinea(…) teniendo en cuenta  escenario  principal  y  todos  los  escenarios  alternativos.  Si  lo  consideráis  oportuno  podéis  añadir  en  la  cabecera indicaciones de lanzamiento de excepciones.    public Tramo crearTramoDeLinea(String color, String nombreEstacion1 String nombreEstacion2) throws NoExisteLineaException, NoExisteEstacionException, TramoExistenteException { Linea l = this.getLinea(color) ; if(linea == null) throw new NoExisteLineaException(color) ; Estacion e1 = l.getEstacion(nombreEstacion1) ; Estacion e2 = l.getEstacion(nombreEstacion2) ; if ((e1 == null)||(e2 == null)) throw new NoExisteEstacionException(); if (null != l.getTramo(e1, e2)) throw new TramoExistenteException(); Tramo tramo = l.creaTramo(e1, e2); return tramo ; } ...