Kitabı oku: «Alexa. Desarrollo de aplicaciones IoT para Arduino y ESP8266», sayfa 6

5.4.6 Prueba del modelo de interacción

Por fin ha llegado el momento de probar el modelo de interacción que acaba de construir. Para ello, suponiendo que siga en la consola del desarrollador de Alexa dentro de la habilidad “Máquina de café”, pulse el botón “Evaluate Model”. En la ventana que aparece, escriba la frase: “Quiero un café con leche y azúcar” y pulse “Submit”.

Recuerde que, para probar un modelo de interacción, previamente tiene que haberlo construido. Evidentemente, dicha construcción debe haber finalizado con éxito (mensaje “Build Successfull”).

Como puede ver en la siguiente imagen, la respuesta obtenida es: “Ha solicitado un café con leche y azúcar. ¿Es correcto?”, que coincide con la expresión de confirmación de la intención “SolicitudCafe” cuando tienen los valores de todos los slots requeridos.

Pero, además de esta respuesta, en la sección “Selected intent” se indica la intención del modelo de interacción desde la que se ha dado, así como el valor de cada uno de dichos slots. En concreto, en el campo “INTENT” se muestra el nombre de la intención y en “RESOLVED SLOT(S)” el valor de cada slot en formato:

nombre slot: valor del slot

El campo “DIALOG ACT” contiene el estado en el que se encuentra el modelo de diálogo desencadenado por la expresión de prueba. Su valor es “ConfirmIntent” porque se está tratando de confirmar si Alexa ha entendido correctamente lo que se ha solicitado, antes de invocar la intención.

Conteste que sí y pulse de nuevo el botón “Submit”. El check verde que aparece a la izquierda del nombre de la intención significa que esta se ha activado, ejecutándose el código que tenga asociado (de momento ninguno), responsable de ejecutar la acción correspondiente.

Su hubiera dicho que no, el resultado sería el mostrado en la siguiente imagen. En este caso, también se ejecutaría el código asociado a la intención, aunque su comportamiento en este caso sería totalmente diferente. Tendrá ocasión de practicar con este tipo de situaciones en una práctica posterior.

Además de la intención invocada, si la habilidad tuviera más intenciones y estas hubieran sido evaluadas (pero descartadas), aparecerían en la sección (“Other considered intents”).

Ahora vuelva a cargar la página de la consola del desarrollador de Alexa. Es imprescindible que se eliminen los datos de la prueba anterior ya que se mezclarían con los de la nueva. Una vez pulsado el botón “Evaluate Model”, introduzca la expresión de prueba: “Dame un descafeinado con leche” y luego presione el botón “Submit”. El resultado lo puede ver a continuación.

Observe que ahora le pregunta: “¿Quiere azúcar, sacarina o sin edulcorante? En efecto, Alexa se ha dado cuenta que el slot “edulcorante” no tiene valor y utiliza la frase del modelo de diálogo de dicho slot (prompt) para preguntárselo. Observe también, que en la sección “Selected intent” se informa de que la intención invocada es, de nuevo, “SolicitudCafe”, y que, aunque sus slots “café” y “leche” tienen valor, no ocurre lo mismo con “edulcorante”. De ahí, que el campo “DIALOG ACT” tenga el valor “ElicitSlot”, indicando que se está tratando de obtener el valor de un slot.

Conteste diciendo: “sacarina” y pulse el botón “Submit”. Ahora obtendrá el siguiente resultado.

Alexa responderá con la pregunta de confirmación: “Ha solicitado un descafeinado con leche y sacarina. ¿Es correcto?”. En la sección “Selected intent”, observe que ahora todos los slots de la intención “SolicitudCafe” tienen un valor, y que Alexa está esperando que se lo confirme (el campo “DIALOG ACT” tiene como valor “ConfirmIntent”). Solo le quedaría contestar que sí (o que no) para que se activara la intención “SolicitudCafe”.

¿Qué hubiera sucedido si cuando le preguntó por el edulcorante que había que añadir, hubiera contestado uno de los que no estuvieran en la lista de valores del tipo de slot “TipoEdulcorante” como, por ejemplo, miel? La regla de validación de dicho slot no se habría cumplido y Alexa hubiera contestado con la frase introducida en el modelo de diálogo: “Solo puede poner azúcar o sacarina. ¿O lo prefiere sin edulcorante?”. Este enunciado dejaría claro lo que se debe elegir, quedando de nuevo a la espera de su elección.

Observe que en la sección “Selected intent” el slot “edulcorante” tiene el valor “miel”, que es el que no ha pasado la regla de validación.

Vuelva a recargar la página de la consola para borrar cualquier dato de la prueba anterior. Ahora póngaselo aún más complicado a Alexa diciéndole: “Prepáreme un café descafeinado”. En este caso, no ha dicho ni la cantidad de leche ni el edulcorante. Por eso, Alexa le preguntará esta información en el orden establecido en su modelo de diálogo: primero, la correspondiente al slot “leche” y, luego, la del “edulcorante”. Ese es motivo por el que ahora, le pregunta: “Solo, cortado o con leche”.

Advierta que en la sección “Selected intent” el único slot que tiene valor es “café”.

Conteste que lo quiere solo y pulse el botón “Submit”. Ahora le preguntará si lo quiere con azúcar, sacarina o sin edulcorante. Dicha pregunta irá orientada a obtener el valor del único slot que queda sin valor (“edulcorante”).

Diga que sin edulcorante y pulse el botón “Submit”. Ya solo quedaría confirmar que el café solicitado coincide con el indicado por Alexa. Hecho esto, se activaría la intención “SolicitudCafe”, que ejecutaría el código que realiza la acción que tenga asociada.

Haga todas las pruebas que se le ocurran, imaginando cómo podría pedir un café el usuario. Comprobará que no todas las entiende correctamente o los slots no toman los valores esperados. Añada nuevas expresiones de muestra o corrija las existentes para ajustar el modelo de forma que se corrijan los errores encontrados.

5.5 FORMATO DE DATOS JSON DEL MODELO DE INTERACCIÓN

Cada uno de los elementos del modelo de interacción que acaba de ver se pueden representar en formato JSON. Dicho formato, de carácter textual, permite la creación y modificación del modelo de interacción de forma ágil y sencilla, sin necesidad de usar las opciones de configuración que acaba de estudiar. Y algo muy importante, reutilizarlo en otros proyectos o con otros usuarios, que no tendrán que repetir los pasos dados en la consola para obtener el mismo resultado.

En los contenidos adicionales, podrá descargar el modelo de interacción de las habilidades desarrolladas a lo largo del libro. No los utilice a no ser que no tenga más remedio porque la mejor forma de aprender es practicando, por muchas equivocaciones que cometa. De los errores es precisamente de donde más enseñanzas obtendrá porque, para resolverlos, tendrá que replantearse todo lo que sabe (o creía saber). De la otra forma, lo único que estaría haciendo es copiar y pegar código.

Para que se familiarice con este formato de datos, primero se explicarán sus fundamentos usando como ejemplo la representación de una placa Arduino como un objeto JSON. Una vez asentados estos conocimientos previos, se describirá el formato de los diferentes componentes del modelo de interacción de una habilidad (intenciones, expresiones de muestra, slots, tipos de slot, etc.) en términos de objetos JSON.

5.5.1 Formato de datos JSON

Con la creciente popularidad de los servicios web, JSON se ha convertido en uno de los formatos de intercambio de datos más utilizados en Internet. Su acrónimo procede del inglés JavaScript Object Notation, delatando a JavaScript como el lenguaje de programación del que procede, que lo utiliza para el intercambio de objetos entre un navegador y el servidor. Dicho formato ha sido posteriormente adaptado para un uso independiente del lenguaje, de ahí su enorme expansión. Propuesto por Douglas Crockford a principios de la década de 2000, fue finalmente estandarizado por primera vez en 2013. Entre las bazas que juegan a su favor están su ligereza (una característica muy valorada en IoT) y gran simplicidad.

JSON está constituido por dos estructuras de datos fundamentales:

• Objetos. Son colecciones no ordenadas de pares atributo-valor. La clave va entre comillas y se separa del valor por el carácter ‘:’. Los pares clave-valor se separan por comas y se enmarcan entre llaves ({}).

• Arrays. Simboliza una lista ordenada de cero o más valores, que pueden ser de cualquier tipo. Los valores se separan por comas y se enmarcan entre corchetes ([]).

Los valores pueden ser a su vez:

• Números. Pueden ser positivos o negativos, enteros o decimales.

• Cadenas de caracteres. Contienen cero o más caracteres entrecomillados.

• Booleanos. Representa los valores true y false

• null. Es el valor nulo.

• Arrays. Los valores de las claves de un objeto o los elementos de un array pueden ser, a su vez, arrays.

• Objetos. Los valores de las claves de un objeto o los elementos de un array pueden ser otros objetos.

Para entender mejor la sencillez de uso de este formato de datos, pero, a la vez, la potencia expresiva que tiene, se va a utilizar JSON para realizar un modelo lógico de una placa Arduino. En primer lugar, considere que cada Arduino tiene un identificador único (que lo distingue de los demás) y que está dedicado a un determinado uso. Además, como ya sabe, existen dos grandes grupos de pines: los analógicos y los digitales. En formato JSON dicho Arduino podría representarse como un objeto con la siguiente estructura:

En el paradigma de programación orientada a objetos, una clase es la representación abstracta de algo, en este caso, un Arduino (entendido, no como un objeto sino como las especificaciones que permitirían fabricarlos). Un objeto es una instancia concreta de una clase. Siguiendo con el mismo ejemplo, sería cada uno de los Arduino que se fabriquen.

Como puede observar, el objeto Arduino tiene cuatro pares clave-valor. La primera (“Identificador”) sirve para distinguir cada Arduino del resto.

La clave “Descripción” tiene como valor un texto que hace referencia al uso que se está haciendo de él. La clave “pines analógicos” contiene un array de String que identifica todos los pines analógicos. La última clave (“pines digitales”) también es un array de String, que en este caso identifican los pines digitales.

A lo largo de este libro se podrá hacer referencia a las claves de los objetos como propiedades o atributos, asimilando la terminología de programación orientada a objetos.

Siga completando este modelo de Arduino. Ahora considere que cada pin se caracteriza, no solo por su identificador, sino también por su valor de entrada y/o salida. De esta forma, lo que antes era un valor primitivo (una cadena de caracteres), ahora es, a su vez, un objeto JSON. Por ejemplo, si el pin “A0” tuviera un valor de 512, esta información podría especificarse en JSON como:

En el caso de los pines digitales, además de su identificador y un valor, también se podría indicar si están configurados como salida digital, salida analógica (PWM) o entrada. Esta última característica sería una nueva clave (“Configuracion”) que podría tomar los valores “ENTRADA”, “SALIDA” o “PWM”. Al igual que con los pines analógicos, lo que antes era un valor primitivo se ha convertido en otro objeto JSON. Por ejemplo, si el pin “D3” estuviera configurado como una salida analógica cuyo valor fuera 255, la representación JSON de dicho pin sería:

Juntándolo todo, cada Arduino se podría describir como un objeto JSON con una estructura similar a la siguiente:

Los caracteres “…” no forman parte de JSON. Se utilizan para indicar que allí deberían estar los objetos que representan a cada uno de los pines analógicos y digitales que faltan, ya que solo se han especificado dos por simplicidad.

Al igual que se ha hecho con Arduino en este ejemplo, todos los componentes del modelo de interacción de una habilidad (intenciones, tipos de slots, etc.) se representan como objetos JSON. Hasta ahora los ha creado usando la interfaz de usuario de la consola del desarrollador de Alexa. A partir de ahora, lo podrá hacer directamente con un sencillo editor de texto y la estructura de los objetos JSON que lo componen.

5.5.2 Objetos JSON del modelo de interacción

Para explicar el formato JSON de un modelo de interacción, se utilizará como ejemplo el de la habilidad “Máquina de café”. Por lo tanto, una vez que haya accedido a dicha habilidad en la consola del desarrollador de Alexa, pulse la opción “Interaction Model” en el menú lateral izquierdo y, luego, sobre “JSON Editor”.

En la parte superior hay una zona a la que podrá arrastrar un archivo JSON para cargarlo en su habilidad. También puede pulsar sobre ella para que aparezca la clásica ventana del explorador de Windows que le permita elegir el fichero que contenga el modelo de interacción que quiera importar.

Más abajo, está el editor con la estructura JSON que contiene el modelo de interacción de la habilidad. Cuando modifique su contenido, deberá guardar y construir de nuevo el modelo (utilizando los botones “Save Model” y “Build Model”) antes de realizar cualquier prueba.

El objeto JSON que representa un modelo de interacción es interactionModel, cuya estructura es la siguiente:

El atributo languageModel tiene como valor un objeto donde se encuentra el nombre de invocación, las intenciones y los tipos de slots personalizados de la habilidad. El atributo dialog almacena el modelo de diálogo de las intenciones que lo tengan. En el atributo prompts están las frases de dicho modelo, utilizadas para obtener la información que debe proporcionar el usuario.

A continuación, se describen en detalle cada uno de estos objetos.

El conocimiento de la estructura de estos tres objetos JSON no es necesario para continuar con la lectura del libro, ya que solo le será de utilidad en caso de que opte por usar el editor JSON para crear o modificar el modelo de interacción de su habilidad.

5.5.2.1 Objeto languageModel

Como se acaba de comentar, el objeto languageModel contiene el nombre de invocación, las intenciones y los tipos de slots personalizados de una habilidad, información que se almacena en los siguientes atributos:

En el atributo invocationName se encuentra el nombre utilizado para invocar la habilidad. Observe su valor en la habilidad “Máquina de café”:

Por otra parte, el atributo intents contiene un array de intenciones representadas como objetos languageModel_intent, donde están las expresiones de muestra y sus correspondientes slots. El atributo types almacena la lista de tipos de slots personalizados en un objeto languageModel_type. Finalmente, modelConfiguration tiene una serie de configuraciones opcionales del modelo (no se estudian por no existir en español).

Veamos ahora la estructura del objeto languageModel_intent, que representa cada intención de la habilidad:

El atributo name es el nombre de la intención. En slots se guardan, como indica su nombre, la lista de slots requeridos como objetos languageModel_intents_slot. Por último, el atributo samples contiene la lista de expresiones de muestra de la intención.

De los atributos anteriores, únicamente quedaría por explicar las propiedades del objeto languageModel_intents_slot:

El atributo name es el nombre del slot, type contiene su tipo y samples la lista de expresiones de muestra de dicho slot.

Veamos cómo sería la estructura JSON de una intención estándar de las que forman parte de la habilidad “Máquina de café”, como, por ejemplo, AMAZON.HelpIntent:

Como puede observar, dicha intención tiene como nombre AMAZON.HelpIntent (tal como cabía esperar) y como expresiones de muestra (atributo samples) una lista vacía. Al igual que en el resto de intenciones estándar, eso es así porque no se ha añadido ninguna adicional a las que ya tiene la propia intención. El atributo slots es opcional, por lo que, al no tener ninguno, este no aparece.

En el siguiente ejemplo se analiza la estructura JSON de la intención “SolicitudCafe”:

Como puede observar, el nombre de la intención es el que usted le dio al crearla (SolicitudCafe). Recuerde que dicha intención tenía tres slots, por lo que el atributo slots contiene un array con tres objetos languageModel_ intents_slots, cuyos nombres (atributo name) son “cafe”, “leche” y “edulcorante”. Dichos slots están asociados a los tipos (atributo type) “TipoCafe”, “CantidadLeche” y “TipoEdulcorante”, respectivamente. Coinciden con los que usted creó y vinculó desde la consola del desarrollador. Respecto a las expresiones de muestra, compruebe que están en el atributo samples todas las que introdujo durante la creación de dicha intención.

Para ver lo fácil que resulta modificar el modelo de interacción usando JSON, añada la expresión de muestra: “Prepárame un {cafe} {leche} y {edulcorante}” a esta intención. Para ello, inclúyala como el último elemento del array que tiene como valor el atributo samples. Luego pulse el botón “Save Model” para guardar el cambio realizado.

Al añadir un elemento al final de un array, tenga cuidado de poner una coma en el elemento anterior. Si la sintaxis de la estructura JSON es incorrecta, aparecerá un pequeño icono con un aspa sobre un fondo rojo a la izquierda de la línea en la que se localice el error.

Una vez guardado el modelo, acceda a la intención “SolicitudCafe”. En el panel principal comprobará que se ha añadido esta nueva expresión de muestra.

Ahora borre dicha expresión pulsando en el icono de la papelera que tiene a la derecha.

Por defecto, las expresiones se muestran en grupos de cinco. Por ese motivo, para poder ver la que acaba de añadir deberá pulsar el enlace “Show All” situado en la parte inferior derecha de la lista de expresiones.

Pulse de nuevo “Save Model” y luego seleccione de nuevo la opción “JSON Editor”. Comprobará que dicha expresión también ha desaparecido del atributo samples de la intención.

Otro de los atributos del objeto languageModel es types, cuyo valor es una lista (array) con los tipos de slots personalizados de la habilidad. Cada uno de ellos es a su vez un objeto languageModel_type con la siguiente estructura:

El atributo name contiene el nombre del tipo de slots. En el atributo values está la lista de entidades que lo componen (valores canónicos y sus sinónimos), cada uno de los cuales es, a su vez, un objeto types_value.

Este objeto también tiene como atributo opcional valueSupplier, que no se va a estudiar.

El objeto type_value solo tiene un atributo (name) cuyo valor es a su vez un objeto value_name, el cual tiene los siguientes atributos:

En el atributo value está el valor canónico y en synonyms la lista de todos sus sinónimos.

Veamos, por ejemplo, los tipos de slots personalizados de la habilidad “Máquina de café”.

Puede observar que el atributo types es un array de tres elementos, correspondientes a los tres tipos de slots personalizados de su habilidad. Cada uno de ellos es a su vez un objeto languageModel_type cuyo atributo name les delata (TipoCafe, CantidadLeche y TipoEdulcorante). El atributo values está completamente desarrollado solo en el primero de ellos (TipoCafe). Su valor es una lista de objetos cuyo único atributo (también llamado name) es a su vez un objeto que representa cada uno de los elementos (entidades) que componen el tipo de slot, es decir, su valor canónico y los correspondientes sinónimos. Así, el valor canónico café descafeinado (atributo value) tiene como sinónimo descafeinado (atributo synonyms), y el valor canónico café normal tiene como sinónimos normal y café. Si recuerda, coinciden con los añadidos en la consola del desarrollador de Alexa a este tipo de slot.