Trabajos

Ejercicio 4: haciendo bien las cosas

Plazo de entrega: 5ª semana

Hoja E4

Introducción

En este ejercicio, aplicará algunas técnicas para mejorar la calidad del software. Como ejemplo de estudio, utilizará el diseño e implementación de su grafo de la semana pasada.

Utilizará modelos de objeto que capturen los invariantes decisivos en el diseño e implementación del grafo. Guardará el invariante de representación y la función de abstracción y los implementará como métodos. Escribirá aserciones en tiempo de ejecución para comprobar las precondiciones, invariantes de representación y otras invariantes internas importantes.

Paralelamente, es muy posible que descubra errores en su código y también es probable que halle modos de mejorar su representación y quizás su especificación. Cuente con que tendrá que volver a escribir gran parte de su código. Le aconsejamos que no tenga mucho código escrito, para que esto no suponga un problema. Existen pocas maneras de mejorar sus habilidades de programación que sean más eficaces que reescribir el código.

Construir modelos de objeto conlleva alguna práctica y, hasta que no tenga cierta soltura, puede resultarle una carga más que un beneficio. Así, el primer problema de este ejercicio le pide que construya algunos modelos pequeños para entornos sencillos y familiares. Hasta ahora, solamente ha visto modelos de objeto de código, en los cuales, los objetos de un conjunto representan objetos de Java™ y los campos representan variables de instancia. En estos modelos más orientados a problemas, tendrá que pensar de forma más abstracta en lo que se refiere a conjuntos de objetos en el mundo real y las relaciones entre ellos. Para comenzar, si quiere, puede consultar el material sobre "modelos de datos" del libro de texto de la asignatura.

Problema 1: precalentamiento para modelaje de objetos (15 puntos)

1. Una baraja se compone de cartas, cada una de ellas con un número y un palo, a excepción del comodín. No hay dos cartas que tengan el mismo número y el mismo palo.
   
2. Una fórmula proposicional es una fórmula-and, una fórmula-or, una formula-not o una fórmula literal. Las fórmulas-and y las fórmulas-or son listas de fórmulas proposicionales. Una fórmula-not es una fórmula proposicional.
3. El espacio aéreo doméstico está dividido en regiones conocidas con el nombre de centros. Cada centro de divide en sectores y tiene un supervisor. A cada controlador del tráfico aéreo se le asigna un único sector.
4. Un libro tiene un prefacio, uno o más capítulos, y a veces un índice. El índice relaciona los nombres de los temas con las páginas del libro. El índice nunca hace referencia a las páginas del prefacio o del mismo índice.
5. Un programa de estudios de licenciatura se compone de asignaturas. Hay varias especialidades. Cada especialidad tiene una asignatura troncal y una o más asignaturas optativas. Una asignatura puede tener condiciones previas: un conjunto de asignaturas que deban cursarse antes de ella. Las condiciones previas para cursar una asignatura se ofertan siempre dentro del mismo programa de estudios de la asignatura. Una asignatura no puede ser un requisito para cursarse a sí misma.

Problema 2: invariantes del grafo (50 puntos)

Construya los siguientes ítems de configuración:

Un modelo de objeto abstracto de su tipo de grafo en el nivel de abstracción de la especificación. Es decir, los objetos del modelo deberían ser aquellos que son visibles a un cliente del tipo.

Un modelo de objeto específico de su tipo de grafo en el nivel de abstracción de la implementación. Es decir, los objetos del modelo deberían incluir todos aquellos que estuvieran implicados en la representación. Asegúrese de que incluye información sobre el mecanismo para compartir objetos, sobre la mutabilidad y sobre qué referencias pueden ser null.

Un invariante de representación para su grafo. Esto debería ser una restricción textual que encajase con el modelo de objeto específico. Indique qué propiedades del invariante de representación son capturadas también por el modelo de objeto específico, y qué propiedades del modelo no aparecen en el invariante de representación. Corte y pegue las declaraciones de los campos pertinentes a su clase (y de otras clases pertinentes que pertenezcan a la representación) para seguir en la línea del invariante.

Una función de abstracción para su grafo. Esto debería definir cómo obtener una instancia del modelo de objeto abstracto, partiendo de una instancia del modelo de objeto específico.

Una implementación del invariante de representación como un método repCheck que no toma argumentos, devuelve voids, y lanza una excepción si el invariante es violado. El método no necesita comprobar cada propiedad del invariante; usted debería aportar un buen juicio de ingeniería sobre qué propiedades son viables para el testeo. No le preocupe que la ejecución del método pueda dañar el rendimiento de la implementación del grafo.

Una implementación de una función de abstracción como un método toString. La cadena devuelta debería representar el valor abstracto con la misma precisión con la que aparece descrita en su modelo de objeto abstracto y en la función de abstracción.

Una lista de problemas (si los hay) detectados en su código al pensar en estos ítems.

Problema 3: tests para el grafo (30 puntos)

Instrumente el código de su grafo con llamadas a repCheck y aserciones en tiempo de ejecución para otros invariantes importantes que espere mantener en puntos del código.

Construya una suite de prueba para su grafo. Para seleccionar sus casos de prueba tenga en cuenta tanto la especificación como la implementación. Sus tests deben alcanzar una cobertura completa de ramas y abarcar todos los casos límites evidentes en la especificación. Intente no utilizar más casos de prueba de los que necesita.

Ejecute los tests utilizando JUnit, e informe sobre los resultados.

Debería entregar:

Una nueva copia del código de su grafo instrumentado con nuevas aserciones y modificado en respuesta a los problemas que encontró en su análisis.

Un conjunto de pruebas comentado para indicar qué casos de prueba proporcionan cobertura y de qué características.

Una lista de problemas (si los hay) que detectó en su código cuando ejecutó los tests.

Un enunciado indicando qué tests tuvieron éxito. Si lo omite, asumiremos que sus tests fallan.

Problema 4: modelado del T (5 puntos)

El metro de Boston (el "T") no es simplemente un grafo cuyos nodos son estaciones y cuyas aristas son segmentos de la vía. Tal vez se haya usted dado cuenta de que su programa, al estar basado en un grafo genérico, no puede manejar con facilidad algunas de las particularidades del T. Si estuviera creando un programa auténtico para la MBTA (Massachusetts Bay Transportation Transportation), necesitaría dar cuenta de estos detalles. Un buen comienzo sería construir un modelo de objeto que capturase la estructura del T y de sus trayectos, los cuales podría utilizar luego como la base para el diseño de algunos tipos de datos abstractos.

Construya un modelo de objeto de este tipo. Tendría que dar cuenta de que un trayecto implica una serie de tramos, cada uno de los cuales es una secuencia de segmentos de la vía en una única línea. También debería incluir la función de facilitar direcciones para Green Line, es decir, que le informe sobre qué tren tomar en Park Street.

Preguntas & Respuestas

Esta sección enumerará las aclaraciones y respuestas a preguntas frecuentes. Intentaremos mantenerla lo más actualizada posible, por lo que le sugerimos que consulte este apartado en primer lugar (después de haber repasado detenidamente la hoja) ante cualquier duda que le surja.

Volver arriba