71456126 enunciado-practica1-afd

PRÁCTICA 1-AFD (convocatoria de febrero) Autómatas y Lenguajes Formales 2011-2012 Página 1

PRÁCTICA 1:

Diseño e implementación de Autómatas Finitos Deterministas.

Aplicación en validación/análisis de cadenas y secuencias de tokens.

Competencias: 1. Ser capaz de diseñar autómatas finitos deterministas (AFDs) con la herramienta JFLAP. 2. Implementar en lenguaje Java métodos para simular el funcionamiento de un AFD con objeto de resolver

problemas de validación y análisis de cadenas simples o estructuradas en tokens.

Material necesario o que sea conveniente consultar en este módulo: 1. En la carpeta de Ayuda y Ejemplos: el documento Tutorial-metodosJavaBasicos.pdf y los ejemplos de

código que se incluyen en Ejemplos-CodigoJava->basicosJava . Nota: se ruega leer la documentación a fondo antes de preguntar dudas por tutoría.

2. Algún tutorial de Java y entorno Eclipse como los que se recomiendan en el tutorial mencionado. 3. Se recuerda que no es competencia de esta asignatura aprender a programa en Java, es un objetivo que

ya se cubre en la asignatura de POO.

Contenido Ejercicio 1: Implentación y prueba de métodos de validación para AFDs. ............................................................ 1 Ejercicio 2: Simulación de un juego modelado mediante un AFD. .......................................................................... 4 Ejercicio 3: Detección de anomalías en secuencias de ECG mediante un AFD. ................................................. 7 Puntuación e instrucciones de entrega......................................................................................................................... 9

Ejercicio 1: Implentación y prueba de métodos de validación para AFDs En la carpeta librerias proporcionamos dos clases necesarias para esta práctica:

Afd.java: permite crear un AFD a partir de un fichero de jflap, guardando los componentes (conjunto de estados, estado inicial, función de transición, etc.) en estructuras de datos adecuadas. Proporciona métodos varios necesarios para simular la ejecución del autómata, por ejemplo, para resetear el autómata, recuperar/establecer el estado o símbolo actual y para obtener el estado siguiente para cierta combinación de estado y símbolo según indica la función de transición representada el diagrama de un fichero jflap (ver código comentado). Hay dos métodos que están vacíos y que hay que implementar en este ejercicio, según indicamos luego.

LectorAFD_JFLAP.java: es una clase que contiene el método leeFichero que se encarga de leer un fichero jflap y extraer los componentes del AFD. El método es invocado por el constructor de la clase Afd.java. Esta clase no debe modificarse y no es necesario comprender cómo funciona.

Creación de un objeto Afd. El método constructor de la clase Afd.java permite construir un AFD a partir de un fichero de jflap y lógicamente puede usarse en otra case para crear cualquier autómata que sea de tipo determinista. Prerrequisito: se supone que el fichero corresponde a un AFD, no a un AFND ni a otro tipo de fichero, si no el funcionamiento de los métodos de esta clase no será correcto. Por ejemplo, en la carpeta Ficheros de prueba tenemos un fichero jflap correspondiente al siguiente AFD:

que usaremos para construir un objeto de la clase Afd:

Afd afdEjem= new Afd("ejem-aa-determinista.jff”);

Al no poner ruta, se supone que este fichero estará en la carpeta del proyecto eclipse que se creará para esta práctica (donde esté el .project), que en principio contendrá las clases Afd.java y LectorAFD_JFLAP. Si no se encuentra ahí se producirá una excepción de E/S.


Una vez creado el objeto afdEjem, pueden invocarse los métodos proporcionados. Por ejemplo:

afdEjem.getEstadoActual(): si es la primera vez que se invoca devolverá el nombre del estado inicial, que en este caso es el string “Q0”. En sucesivas llamadas devuelve el último estado alcanzado por el autómata.

afdEjem.setEstadoActual(“Qaa”): hace que el estado actual pase a ser el que le pasamos como argumento, en este caso el estado identificado por el string “Qaa”.

De forma análoga, podemos obtener el símbolo actual con afdEjem.getSimboloActual() y podemos hacer que cierto símbolo sea el actual con afdEjem.setSimboloActual(simbolo). El tipo del símbolo devuelto o el que se pasa en el argumento puede ser un char (caso de símbolo tipo carácter) o un string (caso de símbolo tipo token). El uso de distintos tipos de símbolos se explica más adelante.

afdEjem.esFinal(estado): devuelve true si estado (un string con el nombre de un estado) es un estado final del autómata afdEjem.

afdEjem.transicion(“Q0”,`a’): devuelve el estado Qa, porque consulta la tabla de transición obtenida a partir del diagrama de transición del AFD del fichero jflap leído y el diagrama indica que desde el estado Q0 leyendo el símbolo a se pasa al estado Qa. Si no hubiera transición definida para el par de (estado, símbolo) que se le pasa como argumento entonces el método transición devolvería null.

afdEjem.reset(): hace que el atributo estadoActual tome como valor el string con el nombre del estado inicial de afdEjem y el atributo simboloActual tome valor null (indicando que aún no se ha leído ningún símbolo). De esa forma se prepara el autómata para que comience una nueva ejecución con una cadena.

IMPLEMENTACIÓN DE MÉTODOS DE VALIDACIÓN EN LA CLASE Afd.java (para entregar)

1. Método de validación (caso de cadenas de símbolos tipo carácter): public boolean esValida(String cadena)

Es el método principal de la clase y simula el funcionamiento de un AFD, procesando la cadena del parámetro carácter-a-carácter, de izda. a derecha, sin acceder dos veces al mismo símbolo y devolviendo true si la cadena es aceptada por el AFD y false si la cadena es rechazada.

Debe seguir la estructura del algoritmo general de simulación de AFD del tema 2 o similar, siempre respetando el modo de funcionamiento de un AFD y usando los métodos listados anteriormente. El método no debe contener instrucciones que no estén relacionadas con el proceso de validación común a cualquier AFD.

Se usarán los métodos de la clase String adecuados para acceder a cada carácter de la cadena de entrada y para controlar que se ha terminado de recorrer la cadena (ver tutorial proporcionado). Este método retorna anticipadamente en el momento en que se detecta una transición no definida.

2. Método público de validación (caso secuencias de símbolos tipo token): public boolean esValida(Scanner secuencia)

En ocasiones, los símbolos de un alfabeto representan eventos o etiquetas que se procesan en secuencia y conviene darle al símbolo un nombre significativo (un string), en lugar de usar caracteres para representar los símbolos. A estos símbolos que se representan mediante un string los llamaremos tokens.

El parámetro de este método es un objeto Scanner, que se supone contiene la cadena a validar y en este caso es una secuencia de tokens separados por uno o más espacios (incluidos newlines). Estos espacios serán ignorados en el proceso de validación.

Ejemplo: supongamos que renombramos los símbolos de AFD "ejem-aa-determinista.jff” y al símbolo a le llamamos alfa y al símbolo b le llamamos beta . Entonces el autómata así modificado acepta la secuencia “betaalfaalfa” (compruébese). Aplicando este nuevo método de validación y considerando ese nuevo autómata entonces el método debería devolver true cuando se le pasa esa misma secuencia, pero separando los símbolos-token con espacios, como en la secuencia “beta alfa alfa”.

Por lo demás la estructura es análoga a la del método de validación para el caso de símbolos tipo carácter, sólo que ahora deberán usarse los métodos de la clase Scanner para extraer tokens de la secuencia uno a uno (ver tutorial) y procesar la secuencia token- a- token en lugar de carácter-a-carácter como en el otro método.

Nota: podemos observar que se usan dos métodos con el mismo nombre y distinto tipo de parámetro (sobrecarga).


IMPLEMENTACIÓN DE MÉTODO DE PRUEBA EN LA CLASE Afd.java (para entregar)

Incluir el método main al final de la clase. Este método sólo tiene por objeto probar los métodos de la clase Afd.java

con un autómata concreto, antes de pasar a usar los métodos de esta clase con autómatas más complejos como los de

los ejercicios siguientes. En main se hará lo siguiente:

Prueba de método de validación con cadenas de símbolos tipo carácter:

1. Crear un Afd a partir del fichero jflap "ejem-aa-determinista.jff”.

2. Invocar al método de validación pasándole una cadena válida y una incorrecta . Para cada cadena de

prueba se imprimirá por consola un mensaje con la cadena procesada y el resultado de la validación (si

acepta o rechaza).

Prueba de método de validación con secuencias de tokens:

1. Modificar el fichero jflap renombrando los símbolos como alfa y beta, como se ha dicho antes.

2. Crear un Afd a partir del fichero jflap modificado.

3. Crear strings de prueba como antes. Ahora los strings contendrán secuencias de tokens separadas

por espacios. Por ejemplo, uno de ellos puede contener la secuencia válida “beta alfa alfa”.

4. Crear un objeto Scanner a partir de cada string de prueba (ver cómo se hace en el tutorial

proporcionado). 5. Invocar al método de validación pasándole al menos un Scanner con una secuencia válida y otro

con la secuencia incorrecta . Para cada secuencia de prueba se imprimirá por consola un mensaje

con la secuencia procesada y el resultado de la validación (si acepta o rechaza).


Ejercicio 2: Simulación de un juego modelado mediante un AFD

Se trata de diseñar un AFD para modelar el mecanismo de control de un juego de canicas en una especie “máquina tragaperras’’, que será simulado en el programa java que habrá que implementar en este ejercicio. Cada jugada consiste en el lanzamiento de una secuencia de canicas por dos zonas de entrada a un laberinto sencillo y cada canica tiene la posiblidad de caer por dos zonas de salida (GANA y PIERDE), como se muestra la siguiente figura:

Descripción del juego:

Hay 3 palancas en el laberinto (P1, P2 y P3). Al inicio de una jugada las palancas están inclinadas hacia la izquierda y se supone que la última canica que cayó por el laberinto perdió (en realidad al inicio no ha caído todavía ninguna canica, pero por defecto se supone eso).

Si una canica entra por la entrada A entonces siempre choca con la palanca P1 y eso hace que la palanca cambie y se incline hacia el lado contrario. Si entra por B la palanca P3 se inclina hacia el lado contrario. La palanca P2 no siempre cambia cuando entra una canica, depende de hacia dónde estén inclinadas las palancas P1 y P3. Si entra por A y P1 está inclinada hacia la izquierda entonces P2 no se mueve porque la canica no choca con esa palanca; sin embargo, si entra por A y P1 está inclinada hacia la derecha entonces la canica choca con P1 y también con P2 (tanto si P2 está inclinada hacia la izda. como si está hacia la derecha) y por tanto estas dos palancas cambian. De forma análoga, cuando la canica entra por B y P3 está inclinada hacia la derecha entonces P2 no se mueve, pero si entra por B y P3 está inclinada hacia la izquierda entonces la canica choca con P3 y también con P2 y ambas cambian su inclinación.

Cada jugada se representa mediante una cadena de A’s/ B’s. Por ejemplo: la cadena “BBAA” es una jugada que indica que se lanzan 4 canicas: la primera entra por la entrada B, la segunda por la entrada B, la tercera por la A y la cuarta por la A. De esta forma el símbolo A representa el evento que se produce cuando una canica entra por la entrada A y el símbolo B representa el evento de entrada por B.

Para cierta jugada, unas canicas caerán por la salida GANA y otras por PIERDE. En cierto instante de la jugada, el hecho de que la canica actual caiga por una de las dos salidas depende de cómo estén situadas las palancas . Por tanto hay que tener en cuenta la situación dada por la inclinación de cada una de las palancas y cómo se altera esa situación cuando entra una canica al laberinto. También se requiere recordar en cierta situación si la canica que acaba de caer dejando las palancas en la situación actual perdió (cayó por PIERDE) o ganó (cayó por GANA), porque hay que llevar la cuenta de las canicas que ganan en cierta jugada.

En el siguiente esquema se muestra una simulación del juego con la jugada representada por la cadena BBAA: se indica cómo van cambiando las palancas a medida que van entrando las canicas (según se lee cada símbolo de la cadena BBAA) y se indica para cada canica si pierde o gana.


Objetivo del juego:

Se procesarán una serie de jugadas de lanzamiento de canicas (cada una es una cadena de A’s/B’s en la simulación). Consideramos dos modalidades de juego:

1. Juego a ``gana la última’’: una jugada obtiene premio si la última canica cae por GANA (el autómata acepta la cadena que representa la jugada). En ese caso decimos que la jugada es ganadora en modo “gana la última”.

2. Juego a ``gana la mayoría ’’: una jugada obtiene premio si el número de canicas que caen por GANA es mayor que el que caen por PIERDE.

MODELADO DE LA DINÁMICA DEL JUEGO CON UN AFD (para entregar)

Diseña en Jflap un AFD que sirva para comprobar si una jugada del juego de canicas, representada mediante una cadena de A’s/ B’s, es o no una jugada ganadora en modo “gana la última”.

Pista: se necesitan más de 10 estados. Da nombres cortos aunque significativos a los estados (con set name en jflap) para que el diseño sea más fácil, dado que hay un buen número de estados y en este autómata es inevitable que se corten los arcos, por lo que resulta poco legible a simple vista y difícil de modificar si los estados no tienen nombre adecuado. El estado inicial representa la situación de ``inicio de jugada’’ indicada en la figura de más arriba. Los estados finales representan la situación en que la canica que acaba de pasar por el laberinto, dejando las palancas en cierta posición, cayó por GANA.


IMPLEMENTACIÓN DEL JUEGO (para entregar)

Implementa una clase ejecutable que haga lo siguiente: Crea un objeto de la clase Afd a partir del fichero jflap con el AFD del juego de las canicas que se pide en el

apartado anterior (se supone que el fichero jflap está en el directorio del proyecto eclipse de esta práctica, no poner ruta).

Imprime un mensaje para que el usuario introduzca su jugada. Puede ser sólo una, o bien varias jugadas separadas unas de otras por una coma (sin espacios).

Aplica el método split (ver tutorial) a la línea introducida por consola para obtener un array de cadenas donde cada una representa una jugada. Se usará una coma como delimitador.

Llama a los métodos que simulan el juego en el modo “gana la última” y en el modo “gana la mayoría”, como se indica a continuación:

Método para simular varias jugadas en la modalidad “gana la última”. o Recorre el array de jugadas y para cada una:

- Invoca al método de validación del objeto Afd creado e imprime un mensaje con la jugada procesada y que diga si con esa jugada se gana o se pierde. - No debe resolverse este ejercicio de otra forma, debe ser mediante el método de validación del autómata.

Ejemplo: si tenemos en el array de jugadas los strings: “AB” y “ABA” entonces se procesa la cadena “AB” y el autómata detecta que gana, porque la última canica entró por B y cayó por GANA, según la descripción del juego y luego se simula la jugada “ABA” y según el autómata con esa jugada se pierde. Método para simular varias jugadas en la modalidad “gana la mayoría”.

o Recorre el array de jugadas y para cada una: o Simula la ejecución del autómata con la cadena correspondiente a la jugada, de forma

parecida a como se hace en el método de validación pero añadiendo instrucciones adicionales para incrementar contadores o lo que sea necesario. No hay que modificar el autómata diseñado en este modo de juego. Deben usarse los métodos públicos definidos en la clase Afd para ir cambiando de estado a mediada que se leen los caracteres de la cadena (entran las canicas al laberinto) y ahora interesa contar las canicas que caen por GANA (se alcanza un estado final).

o Al terminar de recorrer la cadena, se imprimirá un mensaje indicando la jugada procesada y para cada canica se indicará si pierde o gana y luego imprimirá el resultado final: si el número de canicas que caen por GANA es mayor que el que caen por PIERDE entonces gana, en otro caso pierde.

Ejemplo: si tenemos en el array dos cadenas: “BAAA” y “ABA” entonces se procesa la cadena “BAAA” y ganan todas las canicas excepto la penúltima y la jugada es ganadora porque ganan más que pierden. Luego se procesa la jugada “ABA” y en este modo también es una jugada ganadora porque ganan las dos primeras y pierde la última.

Ejemplo de salida del programa: al introducir las jugadas AB,BAAA,ABA,BAB,BABA,AAABBBABABAB la salida que debería ser algo así como: (puede variar la presentación, pero conteniendo la información que se pide) Modo gana la última...

Jugada AB: GANA

Jugada BAAA: GANA

Jugada ABA: PIERDE

Jugada BAB: PIERDE

Jugada BABA: PIERDE

Jugada AAABBBABABAB: PIERDE

Modo gana la mayoría...

Jugada AB:

A(G) B(G) GANA

Jugada BAAA:

B(G) A(G) A(P) A(G) GANA

Jugada ABA:

A(G) B(G) A(P) GANA

Jugada BAB:

B(G) A(G) B(P) GANA

Jugada BABA:

B(G) A(G) B(P) A(P) PIERDE

Jugada AAABBBABABAB:

A(G) A(G) A(G) B(P) B(P) B(G) A(P) B(P) A(G) B(G) A(P) B(P) PIERDE

Jugada ABw3:

A(G) B(G) *** jugada no permitida*** PIERDE


Ejercicio 3: Detección de anomalías en secuencias de ECG con AFD

Plantemos ahora un problema que trata sobre la evolución en el tiempo de la señal de un electrocardiograma (ECG) que, a alto nivel, puede interpretarse como un problema de análisis de secuencias de eventos representados con símbolos tipo token y puede resolverse tomando como modelo un autómata finito determinista.

Figura 1: Ejemplo de registro de señal de ECG

El ECG es el procedimiento de diagnóstico cardíaco por excelencia. En realidad, es un registro gráfico de la actividad

eléctrica del corazón (Fig. 1). El ECG permite estudiar la duración, magnitud y dirección de las fuerzas eléctricas

responsables del funcionamiento del corazón.

Figura 2: trazado de señal de ECG diferenciando componentes

Existen diferentes componentes del trazado típico de señal de un ECG (Fig.2), entre otros los siguientes:

Ondas: pueden ser P, Q, R, S y T.

Segmentos: se distinguen los segmentos ST y PQ.

Complejo QRS.

Intervalos: PQ y QT. La señal continua de ECG se somete a un proceso para convertirla en una secuencia de etiquetas, que llamamos eventos de ECG. Cada evento se corresponde con un componente del trazado de señal del electrocardiograma. Llamaremos secuencia de ECG a una secuencia de eventos que describe la actividad cardiaca durante un determinado intervalo de tiempo. En esta secuencia aparecen de forma cíclica ciertas subsecuencias, que llamamos periodos de ECG. Los periodos válidos del ECG se indican en la figura 3. Una secuencia de ECG normal está formada por uno o más periodos válidos de ECG, en otro caso se trata de una secuencia anómala.


NOTA: los segmentos sST para cada tipo de periodo donde aparecen de manera explícita son opcionales. Es decir, si no aparece alguno para ese periodo, la secuencia resultante se considera un periodo válido también.

Figura 3: Tipos de periodos normales de ECG

Planteamos en este ejercicio esencialmente el problema de comprobar si una secuencia de ECG es normal o anómala. Nota: este problema es una simplificación y no refleja la complejidad real del proceso de diagnóstico médico a través de un ECG. DISEÑO DE UN AFD QUE ACEPTA SECUENCIAS NORMALES DE ECG (a entregar)

Diseña en Jflap un AFD que acepte el lenguaje formado por las secuencias normales de ECG. Los nombres

de eventos que aparecen en la figura 3 forman el vocabulario del autómata. Es un autómata con símbolos de

tipo token, por tanto cada arco se etiqueta con uno de estos símbolos, no con caracteres individuales. No hay

que olvidar que algunos segmentos son opcionales.

Hacer una prueba de ejecución en Jflap, por ejemplo la secuencia “oPsPQiQToPcQRSoT”. Debe aceptarla.

Considera otros casos de secuencias válidas y anómalas para comprobar la corrección del diseño.

PROGRAMA PARA DETECCIÓN DE SECUENCIAS DE ECG ANÓMALAS (a entregar) Implementa una clase ejecutable que haga lo siguiente: Crea un objeto Afd a partir del fichero jflap con el AFD del ECG que acepta secuencias normales. Repite los siguientes pasos hasta que el usuario pulsa enter al pedir el nombre del fichero (el nombre es

vacío). 1. Solicita por consola el nombre del fichero con la secuencia de ECG de un paciente (en la carpeta

comprimida Ficheros de prueba hay ficheros de ejemplo con secuencias de ECG normales y anómalas). No cubren todos los casos, se recomienda diseñar un test de prueba más completo.

2. Crea un objeto File a partir del nombre de fichero y crea un Scanner a partir del File para extraer los tokens (eventos de ECG) del fichero uno a uno (ver tutorial). Se supone que el fichero contiene la secuencia de eventos de ECG separados por espacios. Por ejemplo: si contiene “oP sPQ iQT” esa

secuencia es normal, por lo que el método de validación devolverá true. 3. Aplica el método de validación del objeto Afd creado para comprobar si la secuencia de ECG que se le

pasa es normal o anómala e imprime un mensaje indicando el diagnóstico: normal o anómala (no hay imprimir la secuencia leída porque el fichero puede ser largo). Si la secuencia es anómala entonces debe imprimir además un mensaje informativo de anomalía

con los siguientes datos: estado en que ha parado el autómata al finalizar la ejecución (último estado alcanzado) y último evento de ECG leído. Por ejemplo, si tras leer “oP” estando el autómata en el estado “q1”, se lee “oR” entonces se detecta que secuencia es anómala e imprime mensaje de secuencia anómala junto con el estado “q1” y el evento “oR”. De esa forma nos hacemos una idea de en que tramo de la secuencia de ECG se ha detectado la anomalía.

Nota: la ejecución no debe finalizar si se introduce un nombre de fichero inexistente. Sólo debe acabar cuando el usuario pulsa enter.

oP

oP

sPQ

sPQ

oQ oR oS sST oT

cQRS sST oT

oP sPQ iQT

iPQ oQ oR oS sST oT

Tipo1

Tipo 2

Tipo 4

Tipo 3


Puntuación e instrucciones de entrega

1. Crea una carpeta que se llame Apellidos1-Apellidos2, donde Apellidos1 son los dos apellidos del primer alumno de la pareja de prácticas (todo junto) y Apellidos2 son los dos apellidos del segundo alumno (si es que lo hay). Los que tengan apellido muy largo pueden abreviar. El caso es que quede claro quienes son los autores de la práctica por el nombre de la carpeta. Dentro de esta carpeta:

Incluye las clase LectorAFD_JFLAP.java (original) y Afd.java (modificada) correspondiente al ejercicio 1.

Incluye el fichero Jflap del autómata del ejercicio 2 y la clase con el simulador del juego.

Incluye el fichero Jflap del autómata del ejercicio 3 y la clase con el programa que detecta anomalías en secuencias de ECG.

En cada clase debe aparecer el autor/autores de la práctica al principio, en los comentarios de la clase.

Si alguna clase da errores de compilación o no hace prácticamente nada que no se incluya, porque no contará nada. Es mejor así que entregar cualquier cosa.

No debe aparecer la sentencia package en ninguna de las clases, ni deben incluirse subcarpetas ni .class. Los fuentes (.java) tienen que leerse correctamente en eclipse de Windows. Si se hacen en Linux convierte el formato para que no se vean caracteres extraños.

2. Selecciona la carpeta creada Apellidos1-Apellidos2 (la carpeta, no el contenido de la carpeta) y Enviar a Carpeta comprimida (en zip). No debe entregarse un .rar.

3. En SAKAI sube el .zip para la tarea “PRÁCTICA: Autómatas Finitos Deterministas”:

Cada compañero deben subir el mismo fichero para que quede constancia en el sistema. 4. En SAKAI envía un mensaje privado por grupo (no correo electrónico) a tu profesor con el asunto “Entregada

Práctica 1”.

Únicamente un alumno (si son dos) debe enviar el mensaje.

En el contenido del mensaje indica quiénes son los 2 miembros del grupo (si procede).

Fecha de entrega: la fecha de entrega son las siguientes:

Grupo 1 y 2 (Lunes y Martes): 25 de Noviembre 23:59h. Profesor: José M. Juárez Grupo 3 (Miércoles): 2 de Diciembre 23:59h. Profesor: Antonio Morales.

Puntuación y criterio de evaluación: Esta práctica vale 1.5 del total de 3.5 que se puede conseguir en prácticas. Se recuerda que esta nota ya esta ponderada y suma directamente a la nota de examen (6.5 nota máxima). Se exige una nota mínima de 0.5 en esta práctica. Aquellos que no lleguen a esa nota tendrán que presentar las prácticas en otra convocatoria.

Los ejercicios 1 y 3 valen 0.4 puntos cada uno y el ejercicio 2 vale 0.7 puntos Se restarán puntos por las siguientes deficiencias, según gravedad:

El código contiene fallos de corrección o mal funcionamiento. Como es lógico se requiere que la solución aportada para cada ejercicio sea correcta en general y no que valga para unos casos y falle con otros. La falta de corrección puede suponer restar el total de puntos de un ejercicio.

El código no se ajusta a la especificación establecida en cada ejercicio. Especialmente grave es resolver un ejercicio sin basarse en el funcionamiento del AFD que modela el problema planteado. Esto supone un cero.

El código no tiene comentarios o pocos. Al no pedir que se entregue una documentación, es importante que se comente el código: comentario general de la clase, comentario que aclare lo que hace cada método (al estilo javadoc) y aparte comentar las líneas principales. La ausencia de comentarios puede suponer restar la mitad de lo que vale cada ejercicio, aunque sea correcto.

El código es poco legible. Por ejemplo, con mal sangrado, abuso del scroll horizontal en lugar de partir líneas muy largas, variables sin nombre significativo, etc.

No sigue las instrucciones de entrega. Las instrucciones no son un capricho, tienen por objeto facilitar el trabajo de corrección. Así que se penalizarán los “despistes”, con objeto de reforzar la atención.

En caso de plagio: la copia parcial o total de cualquier ejercicio supone SUSPENSO en prácticas para todas las personas implicadas (los que se copian y los que se dejan copiar).

71456126 enunciado-practica1-afd

Documents

Transcript of 71456126 enunciado-practica1-afd