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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 71456126 enunciado-practica1-afd

Similar a 71456126 enunciado-practica1-afd (20)

71456126 enunciado-practica1-afd