Hace tiempo cuando intentaba aprender Scala, compré el libro Exercises for Programmers y últimamente he dedicado algo de tiempo a hacer uno de los ejercicios, que consiste en un sistema basado en reglas muy simple.
Los sistemas basados en reglas son un subconjunto de los sistemas expertos, que a su vez se engloban en el área de la inteligencia artificial. En el contexto de este artículo, simplificaremos los conceptos, quedándonos con un simple árbol de decisión, que nos permitirá llegar a una conclusión basándonos en las respuestas del usuario.
Podemos encontrar ejemplos de estos sistemas en asistentes paso-a-paso, en las centralitas telefónicas (“Para consultar el saldo, pulse 1”) y en los asistentes digitales como Alexa, Siri, Cortana o Google. Cuando escribimos un sistema de este tipo, nuestra lógica tendrá el siguiente aspecto:
sistema pregunta a.
si usuario responde si:
sistema pregunta b.
si usuario responde = "si"
sistema responde c <- Respuesta final
si no
sistema pregunta d
...
Esta información puede vivir en nuestro código fuente en formato de if, else anidados o puede formar parte de los metadatos de nuestro sistema. En el artículo de hoy diseñaremos uno de estos sistemas utilizando Java y la siempre útil consola de comandos.
Además de escribir nuestro sistema de reglas, en este artículo mencionaremos por encima los siguientes temas:
- Tests unitarios con JUnit y AssertJ
- Generación de Setters y builders con Lombok
- Manejo de Ficheros yaml con snakeyaml
- Inyección de dependencias e inversión de control
- Creación de paquetes JAR con Gradle incluyendo dependencias
Los tests
Una práctica que intento seguir a la hora de hacer este tipo de ejercicios, es empezar por las pruebas al más puro estilo TDD, definiendo de manera inicial el estado al que queremos llegar.
Podemos emplear JUnit y AssertJ para ejecutar los tests, y agregar las referencias a Gradle es tan sencillo como utilizar las siguientes líneas:
testCompile group: ‘junit’, name: ‘junit’, version: ‘4.12’
testCompile(“org.assertj:assertj-core:3.11.1”)
Con ello podemos escribir nuestro primer test:
@Test
public void question() {
assertThat(expertSystem.getMessage()).isEqualTo("Are you able to see any wifi network?");
}
Una vez pedido el estado inicial, hemos de comprobar que el motor pasa del primer estado al siguiente, como hemos en el siguiente test:
@Test
public void firstAnswerYes() {
assertThat(expertSystem.getMessage()).isEqualTo("Are you able to see any wifi network?");
expertSystem.answer(true);
assertThat(expertSystem.getMessage()).isEqualTo("Is the network ID visible?");
assertThat(expertSystem.isDone()).isFalse();
Finalmente, podemos comprobar que hemos llegado a un estado final con el siguiente test:
@Test
public void secondAnswerYesYesDone() {
assertThat(expertSystem.getMessage()).isEqualTo(Are you able to see any wifi network?");
expertSystem.answer(true);
assertThat(expertSystem.getMessage()).isEqualTo("Is the network ID visible?");
expertSystem.answer(true);
assertThat(expertSystem.getMessage()).isEqualTo("Contact your network provider");
assertThat(expertSystem.isDone()).isTrue();
}
Con estos tests, definimos un sistema de reglas que:
- Recibe una respuesta binaria, que puede ser sí o no.
- Proporciona el estado actual así como la información de si el estado actual es final o no.
El motor de reglas
Para este ejemplo, el motor de reglas no es más que un árbol binario con una clase muy sencilla que contiene dos hijos, “sí” y “no”, para cada rama:
@Getter
@Builder
class Stage {
private String status;
private Stage yes;
private Stage no;
boolean isEnd(){
return yes == null && no == null;
}
}
Para crear tanto la construcción de los objetos como los getters como el patrón builder podemos recurrir a Lombok, del que ya hemos hablado en otros artículos de este blog, y que podemos agregar a nuestro modelo de Gradle con las siguientes líneas:
compileOnly ‘org.projectlombok:lombok:1.18.8’
annotationProcessor ‘org.projectlombok:lombok:1.18.8’
A la hora de pasar de una etapa a otra, el motor de reglas simplemente decide qué hijo tiene que buscar:
private Stage current; //Aquí inicializaremos la etapa inicial
public String getMessage() {
return current.getStatus();
}
public void answer(boolean answer) {
if (answer){
current = current.getYes();
} else {
current = current.getNo();
}
}
public boolean isDone() {
return current.isEnd();
}
Una comprobación que no forma parte del código es qué pasa si la etapa ya es final. Por otra parte se podría transformar bloque IF en un operador ternario, dando como resultado algo como current = answer ?? current.getYes() : current.getNo();
El almacenamiento
En el apartado anterior no hemos mencionado cómo inicializar las reglas. Podemos empezar por crear los objetos como parte del constructor, dando como resultado algo así:
Stage root = Stage.builder()
.status(“Are you able to see any wifi network?”)
.yes(Stage.builder()
.status(“Is the network ID visible?”)
.yes(Stage.builder()
.status(“Contact your network provider”)
.build())
.build())
.no(Stage.builder()
.status(“Wireless network might be off. Reboot computer”)
.build())
.build();
Sin embargo, esta aproximación genera un fuerte acoplamiento entre el código y los datos, así que es una buena práctica sacar las reglas del código a un formato diferente, optando en este caso por YAML.
Al transformar nuestro árbol de Java a YAML tenemos como resultado la siguiente estructura, y este fichero lo podemos almacenar en la carpeta resources de nuestro proyecto:
text: "Are you able to see any wifi network?"
yes:
text: "Is the network ID visible?"
yes:
text: "Contact your network provider"
no:
text: "Reboot the wireless router"
no:
text: "Wireless network might be off. Reboot computer"
Para leer el fichero YAML podemos utilizar SnakeYaml, que podemos importar en Gradle con la siguiente línea:
compile group: ‘org.yaml’, name: ‘snakeyaml’, version: ‘1.8’
Finalmente, podemos cargar el fichero YAML en memoria de la siguiente manera.
class YamlLoader implements FileLoader<Stage> {
public Stage loadFromFile() {
Yaml yaml = new Yaml();
InputStream inputStream = this.getClass()
.getClassLoader()
.getResourceAsStream("options.yaml");
Map<Object, Object> obj = (Map<Object, Object>) yaml.load(inputStream);
return getStage(obj);
}
private Stage getStage(Map<Object, Object> obj) {
if (obj == null) {
return null;
}
return Stage.builder()
.status(obj.get("text").toString())
.yes(getStage((Map<Object, Object>) obj.get(true)))
.no(getStage((Map<Object, Object>) obj.get(false)))
.build();
}
}
Para no tener un acoplamiento entre nuestra clase ExpertSystemy YamlLoader, la segunda implementa una interfaz genérica llamada FileLoader que simplemente define un método, lo que nos da la posibilidad de agregar otros gestores de ficheros en el futuro como xml o JSON.
public interface FileLoader <T> {
T loadFromFile();
}
Finalmente la conexión entre nuestra clase ExpertSystemy el gestor de ficheros se realiza en el constructor:
public ExpertSystem(FileLoader<Stage> fileLoader) {
current = fileLoader.loadFromFile();
}
Este último paso no deja de ser inyección de dependencias e inversión de control. De esta manera, nuestra clase ExpertSystem es completamente independiente del formato en el que almacenemos nuestros datos, y podemos probarla de manera aislada, mientras mantenemos nuestra lógica de carga de YAML independiente de la lógica del motor de reglas.
La interacción
Para que nuestro código sea utilizable necesitamos, además de un algoritmo que funcione, una manera de interactuar con nuestro sistema. Para eso, volvemos a los mecanismos basados en System.outy System.in para escribir y leer por la consola.
public class UI {
public static void main(String[] args) {
ExpertSystem system = new ExpertSystem(new YamlLoader());
Scanner scanner = new Scanner(in);
while (!system.isDone()) {
out.printf("%s %s ", system.getMessage(), Option.getOptions());
system.answer(Option.parse(scanner.nextLine()));
}
scanner.close();
out.println(system.getMessage());
}
}
Finalmente, podemos extraer la gestión de la entrada a una clase específica llamada Option:
class Option {
private static final String truthy = "yes";
private static final String falsy = "no";
static String getOptions() {
return String.format("[%s/%s]:", truthy, falsy);
}
static boolean parse(String input) {
if (input.toLowerCase().equals(truthy)) {
return true;
} else if (input.toLowerCase().equals(falsy)) {
return false;
}
throw new IllegalArgumentException();
}
}
Esta clase analizará la entrada que recibimos de la consola y generará un valor verdadero o falso, que luego podemos pasar posteriormente a nuestro motor.
Creando nuestro paquete jar
El último paso de nuestro sistema es empaquetarlo para pode distribuirlo. En nuestro caso lo que queremos es un fichero jar que se pueda ejecutar de manera independiente.
Para ello, hemos de modificar nuestro fichero Gradle para agregar ciertas directivas que, por una parte, establecen la clase principal de nuestro proyecto, y por otra parte, fuerzan a que se combinen las diferentes dependencias que tiene nuestra aplicación. Este paso se muestra a continuación:
jar {
manifest {
attributes "Main-Class": "net.rlbisbe.expert.UI"
}
from {
configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
}
}
Finalmente, solamente tenemos que ejecutar java -jar NuestroPaquete.jar, y podremos ver nuestro sistema en funcionamiento:
Recapitulando
A lo largo de este artículo, hemos visto cómo crear un simple sistema basado en reglas, cómo cargar dichas reglas de un fichero YAML, mientras repasábamos conceptos como inversión de control e inyección de dependencias, pruebas unitarias, y aprendíamos a manejar dependencias en Gradle.
No pierdas la oportunidad de echarle un ojo a Exercises for Programmers que tiene este y otros problemas para aprender nuevos lenguajes, probar maneras diferentes de hacer las cosas o practicar conocimientos.
Puedes encontrar el código fuente de este ejemplo en Github – Expert-System
![[Cloud Running – I] Creando un dashboard en QuickSight con los datos de Strava](https://rlbisbe.net/wp-content/uploads/2019/05/pexels-photo-265087.jpeg?w=1200)
rlbisbe @ dev 