Ufff, ese 'tutorial', es francamente malo... Me recuerda ciertos libros y artículos de revistas, en esa misma línea. Ese tipo de tutorial donde te explican como si fueras idiota, "pulsa aquí, escribe esto, haz lo otro...", no enseñan absolutamente nada.
Un autómata o máquina de estados, es un modelo matemático que se compone de un alfabeto, una serie de estados, una función de transición, un conjunto de reglas, un estado inicial y un estado final. - El alfabeto determina los elementos que puede contener. - El estado inicial, es el modo exacto en que está el autómata al comienzo. Por lo general queda definido por un valor a la entrada. - El estado final, es el modo exacto en que está el autómata al final. Por lo general sólo es de interés el valor de salida. O dicho de otra forma, cada valor de interés a la salida es devuelto. Es común que sea un único valor. - Los estados, son los valores entre los que puede evolucionar internamente el autómata. - La función de transición, determina que valor de estado se toma internamente ante las eventualidades presentes. Esta función generalmente describe en código o se compone de condiciones que examinan el estado actual y la situación en un momento concreto, para decidir el siguiente estado. Suele resumirse en una tabla de estados, que refleja fielmente qué sucede en cada caso. - El conjunto de reglas es lo que diferencia una función de transición respecto de otra. Las reglas se pueden reflejar en un esquema o bien en una tabla.
Como podrás ver, en el 'tutorial' aludido, no se menciona prácticamente nada de todo esto, ni mucho menos aclara qué sucede y por qué...
Existen los autómatas finitos e infinitos, pero en la práctica, sólo podemos operar y llevar a término, los finitos (los infinitos pueden requerir memoria infinita o tiempo de cálculo infinito y no disponemos ni de uno ni de lo otro...).
Los finitos tienen básicamente dos aplicaciones: autómatas reconocedores, aceptadores (comúnmente llamados scanners), o traductores. Estos últimos transforman un valor de entrada en uno de salida, los otros suelen limitarse a 'decir', ok, está bien, o no, está mal... Pero no es infrecuente utilizar un rango mayor de posibilidades que sólo 2. - Un ejemplo de los reconocedores, es por ejemplo la fase de análisis del código fuente de un lenguaje de programación para determinar si el texto recibido pertenece o no a dicho lenguaje... en realidad, ahí hay más de 1 autómata, por ejemplo uno determina si una secuencia de caracteres es o no un número. - Un ejemplo de los traductores, ahondando en el mismo caso, es utilizado cuando por ejemplo el texto del código se pasa desde el lenguaje en que se programó a ensamblador o a código máquina, o a código intermedio durante el proceso de compilación...
En mi opinión harías más avances si usarás de ejemplo el reconocimiento de un token numérico. Más útil y más didáctico, además es un ejemplo donde puedes usar tu mente (pensar, no meramente leer y escribir).
Así el alfabeto lo componen cada digito (0 a 9) y el separador decimal ' Las reglas se condensan en las 4 líneas que describen digito, digitos, sepDecimal y numero. El estado inicial es 0. digito tiene estado 1, cuando se transita de un digito a otro, el estado cambia a 1, es decir no cambia. Si aparece un separador decimal tras un digito transita al estado 2, si tras el separador aparece un digito transita al estado 3. Pero si aparece otro separador tras el separador , transita al estado 4. Y si aparece un carácter que no pertenece al alfabeto transita al estado 5. Si alcanza un estado 3, si aparece otro digito transita a estado 3, es decir no cambia. Y si aparece un nuevo separador transita al estado 4. En resumen, empieza en estado 0, la función continua analizando mientras queden caracteres y el estado sea menor o igual a 3. La aparición de un carácter no definido en el alfabeto transita al estado 5. Los estados finales, pueden ser 0, 1,2,3,4 o 5. Pero los estados de aceptación sólo son 1 y 3. Es decir la función reconocerá el token 'numero', si se devuelve el estado 1, o 3... O directamente resumido un valor TRUE (if estado =1) or (estado=3) devolver TRUE.
Si decides abordarlo, y muestras algún progreso (escribir por escribir, si no hay interés, paso) podría mostrarte el esquema, la tabla de estados y el flujo de la función... Que te servirían de excelente ejemplo para aprender...
Nota que un diagrama de flujo es sustancialmente distinto a una máquina de estados, aunque ambos tienen un carácter de desarrollo, un autómata suees ser específico a una tarea muy determinada. Si bien un autómata puede ser expresado también y fácilmente en un diagrama de flujo, lo opuesto puede llegar a ser inabordable ysi hay cierta complejidad.
En un diagrama de flujo, básicamente expresas todo o parte de lo que un programa hace, además se puede hacer a mayor o menor detalle... una caja puede contener todo un programa, o una simple línea de código... Una máquina de estados opera siempre al detalle mínimo, es decir aborda los detalles del problema en cuestión. ambos pueden ser abstraciones, por cuestiones de generalidad (múltipleas adaptaciones de uso, por pocos cambios para el caso de que se trate).
Los diagramas de flujo centran su interés casi exclusivamente al hehco de tener que mostrar el comportamiento (más exactamente la forma en que se desenvuelve), a terceras personas... sea para enseñanza, sea para que lo programe un tercero, etc...
El autómata centra su interés en 'vehicular' el código necesario cumpliendo todos los condicionantes exigidos. Es decir la idea de crear el autómata es escribir luego el cóodigo libre de errores a sabiendas de que cumple su funcionalidad. Con el diagram de flujo, esto solo es posible cuando el diagrama expresa los detalles más ínfimos, si no es de 'libre implementación' esas partes no detalladas.
Es decir si es para ti mismo un diagrama de flujo, solo pueden llegar a ser necesarios cuando la complejidad o envergadura del sistema exige, dicho tratamiento para abordarlo e ir definiendo partes completas y partes sin terminar o mejorar, o probar... es decir como un planificador de trabajo. En cambio un autómata se hacen necesarios cuando hay muchas condiciones y son complejas y se requiere una alta eficiencia. Además una vez completado un autómata, siempre puede ser optimizado so pena de dejar el código más oscuro.
Como te decía al comienzo, un diagrama de flujo es sustancialmente distinto a una máquina de estados aunque hay puntos en determinadas situaciones donde el diagrama de flujo y la tabla de estados son sinónimo lo uno de lo otro, es decir partiendo de ellos se puede escribir el código subyacente.
...por lo demás, en el enlace los pasos están meridianamente explicados, siguiéndolos al pie de la letra, no te pierdes. La importancia para tal ejercicio, recáe únicamente en que te sirvan de base para poder desarrollar otros diagramas por tu cuenta.
No me gusta (de dicho artículo), el grafismo usado en el desarrollo. Me quedo con la descripción del viejo libro (1970) de Mario Farina (Flowcharting), que pese a su edad sigue vigente, no se han realizado aportes significativos desde entonces.
Particularmente considero que mediante UML, se consiguen desarrollos más sencillos y explícitos de seguir (creo recordar que VS-2008 permitía generar el UML correspondiente a tu código, y no recuerdo si luego en las siguientes versiones lo disgregaron de ciertas versiones). Pero igualmente si no es para que entregar o exhibir a terceros, no suelen tener una utilidad propia, más allá de la comentada cuando la complejidad exige una planificación que facilite su suguimiento y abordaje. Por supuesto tampoco estorba, cuando como el caso comentado, el diagrama era generado a partir del código, algo muy útil para repasar un proyecto de cierta complejidad que hiciste tiempo atrás y del que ya olvidaste detalles...
« Última modificación: 9 Diciembre 2020, 03:01 am por NEBIRE »
Autor
En línea
